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ABSTRACT 


The  goal  of  the  CALS  initiative  is  to  enable  integration  of  enterprises  on  a 
worldwide  basis.  The  vision  is  for  all  or  parts  of  a  single  enterprise,  or  for  example,  an 
original  equipment  manufacturer  and  its  suppliers,  or  a  consortium  of  public  and  private 
groups  and  academia,  to  be  able  to  work  from  a  common  digital  database,  in  real  time,  on 
the  design,  development,  manufacturing,  distribution  and  servicing  of  products.  The  direct 
benefits  would  come  through  substantial  reductions  in  product-to-market  time  and  costs, 
along  with  significant  enhancements  in  quality  and  performance. 

Having  described  the  Continuous  Acquisition  and  Life-cycle  Support  (CALS) 
information  management  system  (IMS)  employed  by  the  United  States  military  to  maintain 
and  distribute  technical  support  documents  for  weapons  and  materials,  this  thesis  proposes 
an  overall  strategy  for  integrating  the  information  management  concepts  of  CALS  into  the 
infrastructure  of  the  Army  of  the  Republic  of  Korea  (ROK). 
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I.  INTRODUCTION 


A.  BACKGROUND 

This  thesis  describes  the  Continuous  Acquisition  and  Life-cycle  Support  (CALS) 
information  management  system  (IMS)  employed  by  the  United  States  military  to  maintain 
and  distribute  technical  support  documents  for  weapons  and  materials.  CALS  also  serves 
as  a  primary  tool  used  in  the  procurement  process  of  these  commodities,  providing  a 
mechanism  for  consistent  and  cost-effective  acquisition.  Additionally,  this  thesis  proposes 
an  orientation  for  integrating  the  information  management  concepts  of  CALS  into  the 
infrastructure  of  the  Army  of  the  Republic  of  Korea  (ROK). 

In  today’s  rapidly  evolving  high-technology  environment  neither  industry  nor 
government  —  including  the  United  States  Department  of  Defense  (DoD)  —  could 
operate  efficiently  with  paper-based  information  processes.  In  the  past,  technical  manuals 
containing  engineering  drawings,  illustrations,  and  textual  data  used  to  support  weapons 
systems  and  materials  were  developed  and  delivered  to  the  United  States  government  in 
paper  form.  The  problems  inherent  to  paper-based  technical  manuals  are  well  illustrated 
by  the  following  example.  In  1980  the  Ml  tank  was  delivered  to  the  U.S.  military  with 
approximately  40,000  pages  of  technical  data  and  8,000  engineering  drawings  for 
maintenance,  whereas,  in  1960  the  M48  tank  required  only  10,000  pages  of 
documentation.  The  U.S.  Navy’s  problem  was  greater:  the  USS  Vincennes  has  23.5  tons 
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of  paper  representing  systems  and  structures  above  the  main  deck  —  more  tonnage  of 
paper  than  of  all  the  weaponry  on  board.  Many  inaccuracies  were  found  within  these 
paper-based  manuals.  In  1992  about  10,000  technical  manual  discrepancies  were 
reported,  and  the  correction  of  these  discrepancies  was  a  very  costly  (up  to  $2,000  per 
page)  and  time  consuming  job.  [Ref.  2:  p.  21] 

In  the  mid  1980’s  the  DoD  sought  to  capitalize  on  advances  in  computer  hardware 
and  in  the  areas  of  computer-aided  design,  computer-aided  engineering,  and  concurrent 
engineering.  The  DoD  structured  a  series  of  military  specifications  and  standards 
facilitating  the  handling  of  weapons  systems'  technical  data  in  open,  digital  formats.  This 
pioneering  effort  grew  into  a  joint  DoD-Industry  CALS  initiative  leading  to  procedures 
governing  acquisitions  from  defense  contractors  through  DoD  acquisition  managers 
conducted  with  technical  data  in  digital  formats.  With  this  change  there  arose  a  need  for 
information  management  systems  that  could  receive,  store,  and  manipulate  technical  data 
in  various  formats.  Additionally,  many  of  the  acquisition  management  procedures 
required  “reengineering,”  applying  concepts  such  as  Business  Process  Reengineering 
(BPR)  to  reap  the  benefits  of  receiving,  handling,  and  managing  technical  data  in  digital 
formats.  [Ref.  4:  p.  1] 

Meanwhile,  major  subcontractors  began  to  implement  Electronic  Data  Interchange 
(EDI)  contracting  programs  with  their  smaller  suppliers.  The  President  of  the  United 
States  made  a  commitment  in  an  October  1993  Executive  Order  to  start  using  EDI  in  new 
procurement  systems  currently  being  developed  across  all  federal  agencies.  The  largest  of 
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the  United  States  procurement  agencies,  the  DoD,  is  notifying  its  existing  and  potential 
suppliers  that  all  simplified  acquisition  procurement  actions  will  be  electronically  based  by 
the  year  1997.  In  support  of  this  action,  the  United  States  Congress  raised  the  simplified 
acquisition  procurement  level  from  $25,000  to  $100,000,  contingent  upon  this  electronic 
achievement  in  the  FY  '95  DoD  Budget  resolution.  The  CALS  strategy  and  government 
and  industry  mechanisms  now  being  defined  and  implemented  can  help  make  it  happen. 
[Ref.  7:  p.  11] 

Using  CALS  as  a  model,  countries  on  the  Pacific  Rim  and  in  Europe  are  realizing 
the  potential  benefits  and  comparative  urgency  of  implementing  a  similar  acquisition 
strategy.  Several  countries  have  been  holding  individual  or  group  CALS  Conferences 
during  the  last  few  years,  such  as  CALS  Pacific  ‘94,  CALS  Japan  ‘94,  and  CALS 
Australia  ‘94. 

The  concepts  and  utility  of  CALS  have  also  sparked  discussion  in  Korea.  The 
Korean  Ministry  of  National  Defense  (MND)  has  developed  new  weapons  systems  (e.g., 
the  Army's  K1  tank,  the  Air  Force's  Korean  Fighter  Program  (KFP),  and  a  destroyer  class 
of  ships  and  the  first  submarine  in  the  Navy)  using  some  non-integrated,  industrial, 
CALS-compatible  applications  (e.g.,  EDI,  SGML,  CAD,  CAM,  etc.).  Recently,  however, 
the  MND  has  recognized  the  relevance  and  significance  of  integrated  CALS  concepts  for 
its  new  weapon  systems,  as  well  as  implementing  CALS  support  for  older  ones. 
Currently,  the  CALS  Committee  of  the  Computer  and  Communication  Promotion 
Association  of  Korea  (CCPAK)  plays  the  leading  role  for  CALS  activities  on  the  industrial 
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side.  On  the  government  side,  the  Ministry  of  Information  &  Communication  (MIC)  and 
the  Ministry  of  Trade,  Industry  &  Energy  (MTIE)  has  established  long  term  plans  for 
implementing  CALS.  Also  MND  is  studying  the  issue  to  develop  a  basic  plan  for  Korean 
CALS  implementation.  In  the  future,  more  detailed  plans  will  be  developed  by  the  Korea 
Institute  for  Defense  Information  System  (IDIS),  and,  the  Agency  for  Defense 
Development  (ADD)  is  slated  to  develop  an  Integrated  Weapons  Systems  Data  Base 
(IWSDB)  as  a  model  for  the  services.  [Ref.  5] 

B.  WHAT  IS  CALS? 

1.  CALS  Origin 

CALS  began  in  the  mid- 1980’s  as  a  defense  industry  project  to  exchange  technical 
data  directly  with  the  government  in  electronic  format  rather  than  on  paper-based 
documents.  [Ref.  2:  p.  17]  After  CALS  became  an  official  program,  the  CALS/CE 
(Concurrent  Engineering)  Industry  Steering  Group  was  established.  This  group  tried  an 
integration  of  various  existing  information  technologies  to  achieve  their  initial  goals, 
continuously  adding  new  elements  as  their  purposes  changed. 

The  early  CALS  goal  of  electronic  interchange  of  technical  data  directly  with  the 
government  was  prompted  by  the  knowledge  that  paper-based  information  is  expensive  to 
produce  and  difficult  to  maintain.  Both  industry  and  government  reasoned  that  electronic 
data  would  be  easier  to  generate,  distribute,  and  maintain,  requiring  less  storage  space, 
and  being  less  costly  and  more  timely  to  update  and  maintain. 
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The  "CALS"  acronym  has  evolved  over  time.  In  1985,  CALS  began  as  “Computer 
Aided  Logistic  Support,”  defined  as  transiting  from  paper-based  weapons  systems 
acquisition  and  support  processes  to  an  integrated  and  automated  environment.  This 
effort  produced,  essentially,  an  electronic  document  management  and  EDI  system 

By  1988  the  name  expanded  to  include  "acquisition,"  becoming  “Computer-aided 
Acquisition  and  Logistic  Support.”  The  new  name  represented  a  two-phase  approach  to 
implementation  that  was  adopted  with  the  long  term  (year  2000)  goal  of  a  shared, 
integrated  database.  In  August  1988,  the  Deputy  Secretary  of  Defense  directed  that 
routine  contractual  actions  be  implemented  with  CALS  throughout  DoD.  Instead  of 
simply  better  management  of  technical  data,  sharing  and  integration  of  data  enabled 
overall  improvements  in  productivity  and  quality.  The  significance  of  these  benefits  was 
recognized  by  government  and  industry  alike,  and  today  the  CALS  strategy  is  being 
adopted  and  adapted  by  organizations  the  world  over. 

In  1993,  the  definition  of  the  project  was  changed  again  to  “Continuous 
Acquisition  and  Life-cycle  Support.”  According  to  the  official  Proceedings  of  the  Seventh 
Annual  Conference  (CALS  EXPO  International  ‘94),  jointly  sponsored  by  DoD,  the 
Department  of  Commerce  and  the  CALS/CE  Industry  Steering  Group,  “this  most  recent 
change  was  meant  to  reflect  the  fact  that  CALS  is  really  about  information  and  process 
improvement,  and  that  both  are  continuous  and  recognizes  CALS  as  a  facilitator  for  world 
wide  process  improvement  and  enterprise  integration.”  [Ref.  2:  p.  17]  Much  of  the  basic 
technology  to  allow  the  initial  goals  of  EDI  is  now  available,  and,  as  stated  earlier,  the 
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President  of  the  United  States  made  a  commitment  in  an  October  1993  Executive  Order  to 


begin  using  EDI  as  part  of  new  procurement  systems  now  being  developed  across  all  the 
Federal  agencies. 

The  emphasis  of  the  CALS  program  continues  to  evolve  as  goals  are  achieved, 
technology  matures,  and  theories  of  business  management  change.  Today,  a  greater 
emphasis  is  placed  on  “reinventing  government”  and  “continuous  process  improvement.” 
CALS  has  been  looked  at  in  this  new  light  to  ensure  that  it  is  coordinated  with  new  ways 
of  doing  business.  There  is  new  emphasis  on  the  underlying  process  instead  of  just 
automating  what  has  always  been  done  before. 

2.  Definition  of  CALS 

Because  CALS  covers  such  a  broad  scope,  it  can  be  defined  in  various  ways  to  suit 
the  context  of  its  use. 

a.  DoD  Aspect 

To  meet  the  challenge  of  ensuring  the  capability  and  readiness  of  DoD 
forces  in  view  of  a  threat  that  has  been  radically  altered  and  is  ever  changing,  a  budget  that 
is  substantially  declining,  and  global  technology  that  is  advancing  rapidly,  DoD  must 
improve  or  reengineer  its  functional  processes  to  decrease  its  weapon  systems  life-cycle 
costs.  In  the  CALS  Strategic  Plan,  DoD  defines  CALS  as  “a  government  and  industry 
strategy  intended  to  enable  more  effective  generation,  exchange,  management,  and  use  of 
digital  information  that  supports  the  life  cycle  of  a  product  through  the  use  of  national  and 
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international  standards,  business  process  changes,  and  advanced  technology  application.” 
[Ref.  3] 


b.  CALS  Industrial  Steering  Group  (ISG)  Aspect 

The  position  of  CALS  ISG,  while  not  unlike  the  government  view  in  basic 
concepts,  is  distinguished  by  its  greater  emphasis  on  the  organizational  rather  than  purely 
informational  aspects  of  CALS  as  a  solution  to  many  of  current  business  problems.  As  a 

solution,  CALS  has  following  benefits: 

•  Providing  longevity  of  information :  CALS  uses  international 

standards,  assuring  access  to  information  created  daily,  ten  or  twenty 
years  from  now  when  software  and  hardware  have  evolved 
dramatically. 

•  Meeting  client  and  user  needs :  Providing  timely  access  to  information 
within  an  organization  and  between  business  partners,  an  organization 
can  better  meet  the  needs  of  its  internal  users,  e.g.,  reducing  data 
re-entry  as  well  as  the  needs  of  external  clients  by  providing  better 
products  quickly  and  less  expensively. 

•  Remaining  competitive :  Costs  are  reduced  with  the  ability  to  rapidly 
access  and  exchange  information  within  divisions  of  organizations,  with 
suppliers,  and  with  business  partners.  Organizations  are  able  to  reduce 
their  costs,  while  producing  more  product,  thus  insuring  their  long  term 
viability. 

•  Eliminating  inefficiency  of  paper-based  systems :  CALS  is  based  on 
electronic  file  formats.  Creating,  exchanging  and  using  information  in 
electronic  form  eliminates  much  of  the  paper  that  currently  exists  in 
offices. 

•  Reducing  costs  while  producing  higher  quality  products :  Shortens  the 
production  cycle  of  products  while  allowing  implementation  of  flexible 
approaches  to  manufacturing  and  access  to  contracts  requiring  CALS 
compatibility. 
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Based  on  these  benefits,  the  CALS  Industry  Steering  Group  recently 
defined  CALS  as  “a  global  strategy  to  further  enterprise  integration  through  the 
streamlining  of  business  processes  and  the  application  of  standards  and  technologies  for 
the  development,  management,  exchange,  and  use  of  business  and  technical  information." 
[Ref  2:  p.  18] 

3.  CALS  Vision 


a.  DoD  Aspect 

CALS'  vision  is  embodied  in  the  DoD’s  stated  strategic  goals  and 
objectives  as  presented  in  the  CALS  Strategic  Plan  ‘93.  In  this  plan,  the  DoD  set  goals 
for  the  advancement  and  application  of  CALS.  Each  goal  has  supporting  objectives,  as 
shown  in  the  fist  below: 

•  To  expand  its  relationship  with  industry  to  ensure  more  harmonious 
methods  of  operation  and  data  exchange.  Warfighting  capability,  the 
readiness  of  forces,  and  effective  combat  operations,  depend  in  large 
part  upon  the  DoD’s  ability  to  capitalize  on  technological  and 
manufacturing  capabilities  of  the  U.S.  industrial  base.  The  DoD  is 
reforming  its  acquisition  process  to  lower  acquisition  and  life-cycle 
costs  of  products  it  buys  and  use  more  commercial  items.  Supporting 
objectives  are:  (a)  Develop  a  DoD  and  industry  infostructure;  (b) 
Enable  “dual-use”  technologies;  (c)  Harmonize  standards  and 
practices;  and  (d)  Provide  CALS  expertise  through  education  and 
training. 

•  To  complete  the  transition  of  its  active  information  and  business 
transactions  to  standard  electronic  formats.  Achieving  the  full  potential 
of  many  business  process  changes  depends  on  acquiring,  accessing,  and 
processing  data  digitally.  Active  data  need  to  be  converted  to  a 
standard  digital  format,  and  the  infostructure  to  process  digital  data 
must  be  in  place.  Considerable  digital  information  must  be  available 
before  the  DoD  and  industry  can  realize  benefits  from  the  CALS 
infostructure.  Supporting  objectives  are:  (a)  Modernize  hardware  and 
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software;  (b)  Acquire  new  digital  data;  (c)  Convert  existing  data  to 
digital  form;  and  (d)  Conduct  business  transactions  in  digitally. 

•  To  continue  progress  toward  integration  of  the  DoD’s  digital 
information.  This  goal  supports  changes  to  business  processes  by 
improving  availability  and  accuracy  of  information.  CALS  will  create 
the  environment  for  a  seamless,  transparent,  and  distributed 
management  of  business  and  technical  information  significantly 
improving  information  availability.  Authorized  users  can  access  this 
information  to  perform  many  functions  throughout  a  system’s  life  cycle. 
The  development  of  a  DoD-wide  information  entity  and  data  model 
with  full  attributed  data  elements  is  a  key  component  of  this  effort  and 
necessary  to  its  success.  Supporting  objectives  are:  (a)  Develop  an 
integrated  infostructure;  (b)  Align  the  Defense  Integrated  Infostructure 
(DII)  with  the  National  Information  Infrastructure  (Nil);  and  (c) 
Promote  business  process  reengineering. 


b.  Industrial  Aspect 

The  CALS  ISG  addressed  a  vision  statement  more  concerning  industrial 
side.  The  vision  is  for  all  or  part  of  a  single  enterprise  (e.g.,  an  original  equipment 
manufacturer  and  its  suppliers,  or  a  consortium  of  public  and  private  groups  and 
academia),  to  be  able  to  work  from  a  common  digital  database,  in  real-time,  on  the  design, 
development,  manufacturing,  distribution  and  servicing  of  products.  Direct  benefits  would 
be  realized  through  substantial  reductions  in  product-to-market  time  and  costs,  along  with 
significant  enhancements  in  quality  and  performance. 


C.  WHY  DOES  THE  ROK  ARMY  NEED  CALS? 


Since  the  Korean  War,  the  United  States  Forces  in  Korea  (USFK)  have  played  an 
important  role  in  maintaining  the  security  of  the  Korean  peninsula.  In  March  1977,  the 
Carter  Administration  announced  its  plan  to  withdraw  all  U.S.  ground  troops  from  Korea. 
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Furthermore,  the  cessation  of  the  Cold-War  increased  the  possibility  of  local  conflicts. 
From  the  early  1970's,  Korea  was  stirred  to  develop  a  self-reliant  defense  posture  by 
various  international  environments.  As  a  result,  MND  decided  that  a  self-reliant  defense 
posture  should  become  a  priority  for  Korean  national  defense. 

Korean  defense  logistics  relied  upon  U.S.  military  aid  until  the  1960's.  In  the 
1970's  MND  started  to  build  a  self-reliant  defense  logistics  support  system;  and  during  the 
1980s  it  developed  into  uniquely  Korean  system.  [Ref.  6:  p.  173]  Also  MND  mentioned 
in  the  Defense  White  Paper  that  ‘‘the  future  logistics  environment  will  feature 
internationalization,  with  military  procurement  sources  diversified  and  the  importance  of 
information  highlighted.”  With  the  goal  of  establishing  a  self-reliant  logistics  support 
system,  MND  has  focused  on  developing  a  comprehensive  defense  logistics  support 
system,  improving  military  supply  systems  and  actively  promoting  international  logistics 
cooperation. 

By  the  definition  of  CALS,  CALS  is  a  global  strategy  for  government  and  industry 
in  the  acquisition  and  logistics  fields.  To  achieve  efficient  management  of  defense  logistics 
resources,  CALS  could  be  a  positive  strategy  for  the  Korean  Military.  The  ROK  Army 
also  needs  CALS  for  cost  reduction.  As  mentioned  earlier,  reliance  on  paper-based 
processes  has  become  exceedingly  expensive.  In  the  Defense  White  Paper,  the  Korean 
defense  budgets’  proportion  of  the  GNP  is  moving  downward,  from  5.2%  in  1988  to 
3.46%  in  1993,  with  forty-five  percent  of  the  Korean  defense  budget  allocated  for  logistics 
support.  This  situation  warrants  the  most  cost  effective  logistic  system  available. 
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Consequently,  implementation  of  CALS  into  the  Korean  Army  Information  Infrastructure 
is  a  reasonable  consideration. 

D.  SCOPE  OF  THESIS 

The  objective  of  this  thesis  is  to  propose  an  implementation  strategy  of  CALS  as 
applies  to  the  ROK  Army.  After  the  Joint  Computer-aided  Acquisition  and  Logistics 
Support  (JCALS)  structure  is  reviewed,  application  areas  that  are  proposed  or  expected  at 
the  DoD  level  will  be  analyzed.  This  thesis  utilized  implementation  lessons  from  the  U.S. 
CALS,  and,  in  that  light,  reviews  the  Korean  CALS.  Afterward,  an  implementation 
strategy  will  be  suggested  for  the  Korea  Army. 

The  thesis  will  be  structured  as  follows.  Chapter  E,  JCALS,  Architecture  and 
Components,  describes  requirements  for  the  DoD  CALS  infrastructure  modernization 
(JCALS).  Chapter  IE,  CALS  Standards  for  Interoperability  and  Integration,  mentions 
standards  for  JCALS  system,  EDI  and  Contractor  Integrated  Technical  Information 
Services  (CITIS).  Chapter  IV,  Application  Focus  Area,  presents  the  applications  which 
the  prototyping  JCALS  site  has  tested,  or  plans  to  test.  Chapter  V,  Recommendation  for 
ROK  Army,  proposes  a  CALS  implementation  strategy  for  ROK  Army.  Chapter  VI 
presents  the  final  conclusion. 
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II.  JCALS  :  ARCHITECTURE  AND  COMPONENTS 


In  CALS'  strategic  plan,  the  DoD  defines  goals  and  objectives  that  it  will  pursue  in 
applying  CALS  throughout  the  Department  of  defense.  It  will  apply  CALS  to  all 
information  -  business  and  technical  -  used  between  and  within  the  DoD,  and  its  industrial 
partners.  Implementation  of  the  CALS  vision  includes  infrastructure  of  the  DoD, 
standards,  policy,  and  regulatory  considerations.  [Ref.  3] 

As  CALS  implementation  guides,  DoD  published  guides  MIL-HDBK-59A  on  28 
September,  1990  and  MIL-HDBK-59B  on  10  June,  1994.  These  guides  provide 
information  and  guidance  for  applying  CALS  strategy  to  the  acquisition,  management  and 
use  of  digital  data  in  support  of  defense  weapons  systems  and  equipment.  Specific 
attention  is  given  to  detailed  planning  and  contractual  implementation  of  CALS 
requirements.  Also,  the  Department  of  Navy  (DoN)  published  the  Navy/Marine  Corps 
Manager's  Desktop  Guide  for  CALS  Implementation  on  30  September,  1994.  This  guide 
provides  a  compilation  of  the  Navy’s  direction  and  intent  for  the  incorporation  of  CALS 
into  defense  system  programs. 

A.  WHAT  IS  JCALS 

JCALS  is  the  DoD  CALS  infrastructure  program  employed  to  embody  CALS 
concepts.  While  CALS  itself  is  a  global  strategy  on  the  part  of  both  industry  and  the 
DoD,  JCALS  was  developed  from  Army  CALS  (ACALS).  In  January  1991,  the  U.S. 
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Army  was  directed  to  include  the  joint  requirements  and  provide  design,  development, 
acquisition,  and  implementation  options  for  a  joint  program 

The  Program  Manager  JCALS  office  defines  that  JCALS  is  a  multi-site, 
interactive,  distributed  data  information  and  management  system.  PM  JCALS  is  a  Joint 
Office  tasked  with  creating  a  digital  environment  which  actively  supports  the 
implementation  of  the  acquisition  and  logistics  requirements  of  the  services  and  Defense 
Logistics  Agency  (DLA).  [Ref.  13] 

The  DoD  CALS  infrastructure  program,  presently  known  as  JCALS,  provides  an 
information  management  system  to  support  uniform  logistics,  acquisition,  engineering, 
manufacturing,  configuration  management,  materiel  management,  and  other  life-cycle 
functional  processes. 

To  test  JCALS  in  each  of  the  services  and  ensure  customer  involvement  and 
satisfaction  early  in  the  design  and  development  stages  of  the  system,  six  prototyping  sites 
have  been  identified: 

•  USAF  Oklahoma  City  Air  Logistics  Center  (OC-ALC),  Tinker  Air  Force 
Base,  Oklahoma. 

•  USAF  Warner  Robins  Air  Logistics  Center  (WR-ALC),  Robins  Air  Force 
Base,  Georgia. 

•  USA  U.S.  Army  Missile  Command  (MICOM),  Redstone  Arsenal, 

Huntsville,  Alabama. 

•  USA  U.S.  Army  Printing  and  Publications  Command,  Alexandria, 

Virginia. 

•  USMC  Marine  Corps  Logistics  Base  (MCLB),  Albany,  Georgia. 
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•  USN  Port  Hueneme  Division  (PHD),  Naval  Surface  Warfare  Center,  Port 
Hueneme,  California.  [Ref.  10:  pp.  2-1] 

The  prototyping  sites  are  the  real  part  of  the  CALS  implementation  within  the 
DoD.  A  prototype  system  is  a  model,  an  experiment,  and  at  best  a  preliminary  version  of  a 
real  system  Prototypes  are  used  as  the  final  design  illustration  of  a  system  to  both  users 
and  designers  and,  as  such,  are  real,  manipulatable,  and  can  be  adjusted.  [Ref.  9]  The 
requirements  applied  to  prototyping  sites  follow  the  CALS  standards  and  implementation 
guides  such  as  MIL-HDBK-59A  &  B  and  the  Navy/Marine  Corps  Manager's  Desktop 
Guide  for  CALS  Implementation. 

B.  GENERAL  JCALS  SYSTEM  DESCRIPTION 

1.  Deployment 

Planned  to  begin  approximately  in  the  last  quarter  of  1995,  the  deployment  of 
JCALS  systems  will  be  accomplished  at  approximately  250  military  and  DLA  installations 
over  several  years.  JCALS,  together  with  Joint  Engineering  Data  Management  and 
Information  Control  System  (JEDMICS),  will  be  a  major  manifestation  of  the 
implementation  of  the  DoD's  CALS  strategy.  [Ref.  16] 

JCALS  sites,  each  of  which  is  supported  by  its  own  Fiber-Optic  Distributed  Data 
Interface  (FDDI)  backbone  and  departmental  LANs,  will  be  interconnected  by  a  WAN 
that  relies  on  DISN  assets  and  capabilities.  The  connectivity  offered  by  the  WAN  as  well 
as  the  configuration  of  each  JCALS  site  is  depicted  in  Figure  2-1. 
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Figure  2-1.  JCALS  Architecture. 

2.  Infrastructure 

The  JCALS  system  is  an  open  architecture  design.  This  design  style  provides  for 
the  fixture,  and  is  also  an  environment  that  can  easily  be  modified  to  keep  pace  with 
changing  computer  technology  and  that  can  easily  be  tailored  to  local  requirements.  For 
example,  peripheral  equipment  that  are  required  at  particular  JCALS  sites  can  be 
accommodated  by  simply  adding  them  to  the  initially  deployed  system  and,  since  a  very 
high  percentage  -  approximately  95%  -  of  the  system  software  is  COTS 
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(commercial-off-the-shelf),  applications  can  be  changed  or  added  with  relative  ease.  Even 
though  each  site  can  utilize  differing  quantities  and  types  of  peripheral  equipment,  the 
basic  configuration  at  each  site  will  be  functionally  identical. 

The  infra  structure  of  JCALS  system  should  include  several  means  of 
communicating  over  geographic  distances  that  provide  the  JCALS  users  powerful  tools 
for  accomplishing  a  large  percentage  of  their  daily  tasks.  These  means  include:  the  JCALS 
Workflow  Manager,  JCALS  Workfolder,  JCALS  In  Box/Out  Box  utilities,  and  JCALS 
Mail  system.  The  infrastructure  designed  and  deployed  as  JCALS  system  provides  the 
basis  for  the  DoD  to  begin  implementing  the  CALS  initiative  that  began  in  the  mid-1980's. 
The  initial  functionality  included  in  the  initial  deployment  of  the  system  is  the  Technical 
Manual  system  [Ref.  16] 

3.  JCALS  Infrastructure  Capability  Features 

Several  major  features  in  the  JCALS  system  provide  basic  infrastructure 
capabilities  that  permit  fulfillment  of  the  CALS  initiative.  The  following  paragraphs  briefly 
describe  these  features.  [Ref.  16] 

a.  Reference  Library/Reference  Library  Search 

A  significant  portion  of  the  JCALS  infrastructure  is  the  Reference  Library  - 
a  major  element  of  the  JCALS  distributed  data  base  capability  -  and  the  means  to  search 
the  library  for  specific  documents.  The  library  provides  users  with  an  electronic  repository 
for  publications,  documents,  engineering  drawings,  graphics,  etc.,  that  are  available  in  the 
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JCALS  system.  This  library  provides  JCALS  users  with  worldwide  access  to  any 
publication,  document,  drawing,  etc.,  that  they  may  need.  Depending  upon  an  individual's 
permissions  or  authority  established  in  their  assigned  user  ID  code,  they  will  be  able  to 
view  and/or  revise  the  source  documents  contained  in  the  Reference  Library.  All  items  in 
the  Reference  Library  are  cataloged  based  on  a  number  of  categories  such  as  data  type, 
subtype,  responsible  service,  proponent,  etc.  The  Reference  Library  Search  capability 
provides  users  with  a  choose/filter  window  to  define  criteria  that  the  system  will  use  to 
locate  the  exact  documents  the  user  desires.  [Ref.  16] 

b.  Workflow  Manager 

A  second  major  system  infrastructure  tool  provides  the  means  to  create  and 
define  a  sequence  of  tasks  associated  with  a  job  and  also  create  a  workfolder  necessary  for 
that  job.  Also  provided  as  part  of  this  capability  is  the  capability  of  monitoring  the  status 
of  a  job  as  it  is  being  produced  and  generate  a  report  that  shows  the  status  of  a  job  and  all 
in-process  tasks.  A  completed  and  saved  workflow  creates  all  database  links  that  are 
necessary  to  associate  personnel,  data,  documents,  and  time  (schedule)  to  a  given  job  and 
all  of  the  tasks  associated  with  that  job.  [Ref.  16] 

c.  Workfolder 

Another  part  of  the  JCALS  system  that  is  also  a  major  part  of  the  basic 
system  infrastructure  tool  set  is  the  Workfolder  process.  This  capability,  when  used  in 
conjunction  with  the  Workflow  Manager  tool,  provides  easy  access  to  all  data  and  tools  a 
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user  needs  to  perform  assigned  tasks.  When  a  task  is  assigned,  a  workfolder  is 
automatically  delivered  to  the  first  task  manager  (user)  through  the  user's  In-Box  icon  on 
the  Desktop.  Once  a  user  opens  a  workfolder  for  the  first  time,  it  will  automatically  be 
placed  in  the  user's  Service.  The  user  will  retain  access  to  a  given  workfolder  until  the  job 
is  completed,  even  though  that  user  might  have  completed  the  assigned  task.  The 
workfolder  does  not  contain  actual  data  -  rather  it  contains  pointers  to  data  that  are  stored 
in  the  JCALS  distributed  database.  Since  all  of  the  users  working  on  a  job  can  view  and 
access  data  simultaneously,  the  workfolder  promotes  sharing  of  information  that  is 
necessary  for  concurrent  task  efforts.  [Ref.  16] 

C.  JCALS  SYSTEM  COMPONENTS 

A  key  element  of  the  JCALS  System  is  the  distributed  information  management 
system,  which  implements  the  Integrated  Weapon  System  Data  Base  (IWSDB).  This  data 
base  contains  data  that  is  physically  resident  on  JCALS  hardware  and  data  that  is  virtually 
resident  in  data  bases  on  interconnected  existing  systems.  The  information  in  the  data  base 
is  available  transparently  to  all  users  at  all  sites  via  the  Global  Data  Management  System 
(GDMS).  The  JCALS  System  hardware  and  software  are  divided  into  three  major 
components  in  the  client-server  architecture.  [Ref.  12] 

1.  Workstation  Management 

The  Workstation  Management  component  supports  all  processing  and  information 
services  to  the  functional  users.  It  provides  all  the  tools  and  utilities  users  require  to 
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retrieve,  create,  edit,  and  share  technical  data,  as  well  as  manage  and  coordinate  all  work 
activities  involved  with  the  technical  processes  being  automated  and  standardized.  A 
Workstation  Server  (WSS)  processor,  and  its  associated  software  and  peripheral 
equipment,  functions  as  server  to  a  group  of  client  workstations  connected  to  it  on  a 
work-group  LAN.  It  functions  as  a  client  of  the  Data  Management  component  when 
access  to  the  IWSDB  is  required.  [Ref.  12] 

2.  Network  Management 

The  Network  Management  component  consists  of  all  communications  hardware 
and  software  required  to  provide  secure  data  communications  and  connectivity  for  the 
JCALS  system.  It  includes  local  and  wide  area  communications  networks  to  provide 
common  connectivity  among  JCALS  system  elements.  The  Network  Management 
component  functions  as  a  server  to  other  components  at  the  same  site,  and  is  both  a  server 
to  -  and  a  client  of  -  the  Network  Management  component  at  remote  sites.  For 
prototyping,  the  Network  Management  component  is  configured  on  the  Data  Management 
Processor.  [Ref.  12] 

3.  Data  Management 

The  Data  Management  component  controls  and  coordinates  the  services  required 
to  access  and  manage  the  Integrated  Weapons  System  Distributed  Data  Base  (IWSDB).  In 
particular,  it  provides  the  Global  Dictionary/Directory  Data  Base  (GD/DDB)  services 
required  to  identify  and  locate  information  in  the  distributed  GDMS  which  provides 
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integrated  views  of  data  across  multiple  JCALS  sites  and  external  systems.  This 
component  is  a  server  to  both  local  and  remote  users  who  need  access  to  data  stored  on 
the  server.  It  is  also  a  client  of  its  equivalent  component  at  remote  sites  where  data 
needed  by  local  users  is  stored.  [Ref.  12] 

D.  HOST  ENVIRONMENT 

If  data  users  do  not  have  access  to  the  appropriate  hardware,  software,  and 
telecommunications  equipment,  working  in  a  digital  data  environment  can  become  an 
obstacle  course.  Computer  hardware  must  have  appropriate  processing  speed  and  display 
capability  to  run  the  application  software  adequately.  Application  software  must  perform 
specific  tasks  on  the  data  that  are  required  by  the  user.  Rather  than  re-create  data,  the 
appropriate  computer  networking  system  should  allow  users  to  share  data  and  resources, 
and  telecommunications  equipment  should  allow  users  to  transfer  data  easily. 
[Ref.  11:  pp.  4-6] 

1.  Hardware  Requirements 

Computer  hardware  consists  of  the  computer  processor,  memory,  monitor,  storage 
devices,  and  input  devices.  Most  engineering  and  business  single  user  computers  use 
either  an  80486-based  processor,  a  68040-based  processor,  or  a  Reduced  Instruction  Set 
Computing  (RISC)  based  processor  such  as  the  RS-6000. 

The  80486  and  68040  Personal  Computers  (PCs)  are  the  most  widely  used 
computers  and  are  ideal  for  data-intensive  applications  that  require  low-  to 
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medium-graphic  displays.  RISC  workstations  are  widely  used  in  engineering  and  technical 
publishing  applications  that  require  either  a  powerful  processor  for  extensive  calculations 
or  a  high-resolution  graphics  display  for  document  editing.  A  "diskless"  RISC 
workstation  may  provide  a  low-cost  solution  to  some  engineering  computing  needs.  These 
workstations  typically  have  a  small  hard  disk  for  the  operating  system  while  the 
application  software  and  user  files  are  loaded  from  a  network  server.  A  third  option  is  a 
graphic  display  workstation  that  supports  the  X-Window  Motif  standard.  However,  a  PC 
with  X-Windows  emulation  software  may  provide  the  same  features  at  lower  cost.  The 
standard  options  for  each  type  of  computer  is  presented  in  Table  2-1. 


Table  2-1.  Standard  Options  for  PC  Types  [  Ref.  11:  pp.  4-71 


WINDOWS 

WORKSTATION  TYPE  1 

RISC 

WORKSTATION  TYPE  2 

Processor 

486  DX  -  33  /  68040- 

RISC  Workstation 

memory 

16  Mb 

32  Mb 

Media 

i .  i . '• . . l 

i  ni  .  "  j 

Hard  Drive 

350  Mb 

500  Mb 

Floppy  Drive 

3.5  &  5.25 

3.5 

Tape  Drive 

Optional 

Yes 

CD  Drive 

Yes 

Yes 

WORM 

Optional 

Optional 

Monitor 

17"  -  19"  Flat  SVGA 

19”  -  21”  High  Res 

Typical  Cost 

$2,500  to  $5,000 

$5,000  to  $50,000 
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2.  Software  Requirements 


The  JCALS  software  architecture  is  based  on  the  use  of  industry  standards  to 
provide  an  open  architecture.  From  a  user's  perspective,  the  most  important  aspect  of  the 
software  architecture  is  that  it  provides  an  intuitive,  easy-to  use  interface  to  the  functions 
performed  by  the  computer  system. 

The  cornerstone  of  the  JCALS  software  architecture  is  the  graphical  desktop.  The 
X-desktop  is  the  selected  product  as  the  graphical  user  front  end  to  the  system  X-desktop 
is  a  customizable  graphical  user  environment  that  enables  users  to  configure  their  working 
environment.  By  providing  a  familiar  graphical  workspace,  X-desktop  facilitates  the 
execution  of  applications  software  and  the  management  of  information  in  a  sophisticated 
open  systems  environment. 

Aster’x®,  a  Motif-based  office  automation  package,  provides  word  processing, 
electronic  spreadsheet,  and  graphics  capabilities.  This  package,  together  with  the  calendar, 
calculator,  and  electronic  mail  packages  bundled  with  ULTRIX®  MLS+  and  X-Windows, 
satisfies  the  office  automation  functional  requirements.  Workflow  management 
functionality  is  provided  as  developed  software.  These  products  are  augmented  by  a 
project  management  capability  provided  by  the  Ultra  Planner®  package  from  Productivity 
Solutions. 

In  the  technical  publications  area,  JCALS  has  a  CALS-compliant  publishing 
solution.  JCALS  also  has  a  Standard  Generalized  Markup  Language  (SGML)  capability 
available  through  the  use  of  an  SGML  editor  by  Arbortext.  Technical  illustrations  will  be 
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produced  by  Intercap  Quickedit®  and  Intercap  Illustrator  2®,  which  is  the  selected  tool  for 
converting  computer-aided  design  (CAD)  drawings  into  exploded-view,  isometric 
technical  illustrations.  The  actual  publishing  will  be  performed  using  Arbortext's 
Publisher®  and  Datalogics  CALS  Applications  software.  [Ref.  12] 

E.  NETWORKS 

Deployment  of  the  JCALS  production  system  is  envisioned  for  approximately  250 
military  and  DLA  installations.  [Ref.  15]  They  will  be  interconnected  through  a  DoD 
worldwide  digital  telecommunications  system  managed  by  the  Defense  Information 
Systems  Agency  (DISA).  A  user  at  any  site  will  he  able  to  access  data  available  at  any  of 
the  other  sites.  [Ref.  13] 

Thusly,  all  benefits  to  be  derived  from  JCALS  are  dependent  on  communication, 
whether  it  be  across  the  office,  across  the  base,  or  across  the  country.  Communications  in 
the  prototype  environment  are  restricted  to  within  individual  sites  and  between  prototype 
sites.  Prototyping  efforts  have  shown  the  efficacy  of  the  JCALS  communication  system  in 
this  limited  setting.  The  ability  to  communicate  and  share  data  between  these  sites  and 
major  industrial  partners,  as  well  as  the  ability  to  share  data  and  perform  local  business 
processes  in  an  electronic  environment,  is  the  backbone  of  JCALS.  The  system  will  reside 
on  each  site's  local  area  network  (LAN)  and  communicate  over  a  wide  area  network 
(WAN)  with  the  other  sites,  the  System  operational  Support  Center  (SOSC),  and 
industrial  partners.  [Ref.  15] 
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In  MEL-HDBK-59A,  the  DoD  notes  that  the  telecommunications  plan  of  CALS 
details  an  approach  to  the  development  of  capabilities  and  telecommunications  services 
required  to  support  CALS  activities,  consistent  with  the  phased  DoD  migration  to  Open 
Systems  Interconnection  (OSI)  standards;  and  that  the  telecommunications  model  for 
CALS  describes  the  services  site  processes  required  for  a  successful  implementation. 
These  services  are  described  by  modeling  site  configurations  and  interactions.  [Ref.  17] 

Each  prototype  site  has  developed  their  telecommunication  systems  to  fit  these 
directions.  This  section  will  refer  to  the  PHD  NSWC's  examples  for  networks 
architecture. 

1.  Local  Area  Network 

The  JCALS  prototype  communicates  at  PHD  NSWC  via  a  LAN  dedicated  to 
JCALS  traffic.  The  program  utilizes  four  strands  of  Fiber-Optic  Distributed  Data  Interface 
(FDDI)  fiber-optic  cables.  The  FDDI  LAN  connects  five  buildings  in  the  PHD  NSWC. 
Deployment  the  JCALS  system  will  reside  on  the  station  backbone  LAN  and  be  available 
at  approximately  142  "seats"  at  PHD  NWSC.  [Ref.  15] 

2.  Wide  Area  Network 

JCALS  prototype  system  communicates  with  remote  sites  via  a  Defense 
Information  Systems  Agency  (DISA)  Wide  Area  Network  (WAN)  (DISN).  This  WAN 
links  PHD  NSWC  with  the  SOSC  and  the  other  JCALS  prototype  sites.  JCALS  at  PHD 
NSWC  is  communicating  with  Defense  Printing  Service  (DPS)  at  the  Naval  Construction 
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Battalion  Center  (CBC)  Port  Hueneme  via  a  56  Kbps  circuit.  The  DISN  will  continue  to 
be  the  WAN  utilized  by  JCALS  after  deployment.  [Ref.  15] 

F.  GLOBAL  DATA  MANAGEMENT  SYSTEM 

JCALS  will  be  facilitated  through  the  use  of  its  multi- weapons  systems  IWSDB, 
Global  Data  Dictionary  and  Directory  (GDD/D)  services,  extensive  networked 
telecommunications,  and  its  strict  adherence  to  CALS  and  Corporate  Information 
management  (CIM)  Technical  Reference  Model  (TRM)  standards.  Data  residing  in  the 
JCALS  system,  or  in  any  system  to  which  JCALS  will  interface  (including  JEDMICS),  will 
be  transparently  available  to  any  user  with  a  need-to-know  and  proper  access  privileges. 
The  system  will  provide  uniform  applications  and  services  to  implement  joint  functional 
processes  through  the  use  of  the  JCALS  Workbench.  This  workbench  will  provide  a 
uniform  human-user  interface  (HUI)  and  will  give  transparent  access  to  all  data, 
applications,  and  software  tools  available  throughout  the  architecture.  The  system, 
through  the  workbench,  will  provide  a  flexible  work-flow  management  capability  which 
will  he  tailored  to  suit  the  organizational  structure  of  the  service,  command,  or  workplace 
while  ensuring  that  future  changes  can  be  accommodated  easily.  [Ref.  8:  p.  34] 

1.  Integrated  Weapon  Systems  Database  (IWSDB) 

The  JCALS  IWSDB  will  provide  a  multi- weapons  systems  repository  that  services 
multiple  acquisition  and  logistic  functions.  IWSDB  will  read,  write,  modify,  delete,  and 
grant  application-usage  permission  on  a  need-to-know  basis.  Enforcement  will  be  by  a 
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multi-level  secure  (MLS)  trusted  computing  base  (TCB)  rated  initially  at  a  B1  level  of 
trust  and  progressing  to  a  B3  level.  JCALS  will  provide  transparent  access  to  technical 
information  regardless  of  where  it  resides  within  the  IWSDBs'  distributed  databases.  All 
technical  information  will  be  strictly  configuration  managed.  Configuration  impacts  due  to 
changes  will  be  identified  by  the  JCALS  object-oriented  data  management  service. 
[Ref.  8:  p.  35] 

2.  Global  Data  Management  System  (GDMS) 

The  JCALS  GDMS  will  provide  the  services  required  to  access  and  manage  the 
distributed  data  of  the  IWSDB.  The  GDMS  will  respond  to  requests  from  applications  or 
requests  stored  internally  to  JCALS  to  access,  store,  and  manage  data.  One  example  of 
responding  to  requests  stored  internally  is  the  production  of  summary  data  from  an 
existing  system  to  be  stored  on-line  for  access  by  system  users. 

The  GDMS  will  store  data  in  the  IWSDB  in  a  physically  distributed  manner.  Data 
may  be  stored  where  the  data  was  created,  where  the  data  will  be  used  most  frequently,  or 
in  an  existing  system  which  already  contains  this  type  of  data.  This  will  involve  managing 
physically  distributed  data  that  may  not  reside  in  the  same  location  as  the  owner/proponent 
of  the  data. 

The  GDMS  will  ensure  the  correctness  of  the  user  and  application  views  and 
maintain  the  integrity  of  data  accessed  and  modified.  The  GDD/D  database  will  serve  as  a 
repository  of  data  management  policy  and  data  integrity  requirements  for  data  stored  in 
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the  IWSDB.  Existing  systems  will  retain  control  and  integrity  responsibilities  for  their  own 
data.  The  GDMS  will  ensure  that  access  of  existing  systems  data  does  not  violate  the 
official  ownership  or  integrity  rules  of  that  system.  The  execution  of  an  existing  system's 
programs  will  be  directly  under  the  control  of  the  existing  system.  [Ref.  8:  p.  35] 
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ffl.  CALS  STANDARDS  FOR  INTEROPERABILITY  AND 

INTEGRATION 


A.  IMPLEMENTATIONS  OF  THE  CALS  MANDATE 

In  August,  1988,  the  Deputy  Secretary  of  Defense  cited  the  first  mandate  of  CALS 
usage  for  the  acquisition  of  new  weapons  systems  and  major  equipment  in  a  memorandum 
to  secretaries  of  the  military  department  and  the  Defense  Logistics  Agency.  This 
memorandum  cited  that  the  CALS  standards  would  enable  either  digital  data  delivery  or 
government  access  to  contractor-maintained  technical  data  bases  and  that,  effective 
immediately,  plans  for  new  weapons  systems  and  related  major  equipment  items  should 
include  use  of  the  CALS  standards. 

The  CALS  standards  were  specified  for  two  types  of  systems: 

•  For  systems  now  in  full-scale  development  or  production,  program  managers 
shall  review  specific  opportunities  for  cost  savings  or  quality  improvements 
that  could  result  from  changing  weapons  systems'  paper  deliverables  to  digital 
media  for  delivery,  or  access  to  the  data  using  the  CALS  standards. 

•  For  systems  entering  development  after  September  1988,  acquisition  plans, 
solicitations,  and  related  documents  should  require  specific  schedule  and  cost 
proposals  for:  (1)  integration  of  contractor  technical  information  systems  and 
processes;  (2)  authorized  government  access  to  contractor  data  bases;  (3) 
delivery  of  technical  information  in  digital  form. 

This  memorandum  was  later  codified  in  the  Defense  Federal  Acquisition 
Supplement  (DFARS).  DFARS  tasks  acquisition  managers  and  program  offices  for 
planned  acquisitions  to: 

•  Implement  CALS  standards  in  new  defense  system  acquisitions  with  CALS 
requirements  being  incorporated  in  the  Request  For  Proposal  (RFP)  and 
eventually  the  contracts; 

•  Describe  the  extent  of  how  the  CALS  standards  have  been  implemented  in 
their  acquisition  planning; 
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•  Ensure  that  their  offices  have  the  sufficient  computer  technology  infrastructure 
in  place  and  are  capable  of  receiving  and  managing  digital  data. 

For  weapons  systems  already  in  the  DoD  inventory,  DFARS  requires  mangers  to 
exploit  the  CALS  standards  by  converting  existing  paper-based  technical  data  to  digital 
data.  [Ref.  4] 

On  June  29,  1994,  Secretary  of  Defense  William  J.  Perry  issued  a  memorandum  to 
the  Secretaries  of  the  Military  Departments  and  the  Directors  of  the  Defense  Agencies 
directing  that  "performance  specifications  shall  be  used  when  purchasing  new  systems, 
major  modifications,  upgrades  to  current  systems,  and  nondevelopmental  and  commercial 
items,  for  programs  in  any  acquisition  category.  If  it  is  not  practicable  to  use  a 
performance  specification,  a  non-government  standard  shall  be  used."  Secretary  Perry 
allowed  the  use  of  military  specifications  and  standards  in  cases  where  performance 
specifications  or  non-government  standards  are  not  cost  effective.  The  memorandum 
went  on  to  state  that  military  specifications  and  standards  listed  in  the  DFARS,  such  as  the 
CALS  initiative's  military  specifications  and  standards,  are  no  longer  mandatory  and 
should  be  viewed  only  as  guidance  by  program  mangers.  [Ref.  4:  p.  16] 

How  will  the  CALS  effort  be  sustained  under  these  conditions?  As  an  example  of 
how  the  Services  balance  the  apparently  conflicting  guidance  received  from  the  Secretary 
of  Defense  in  1988  and  1994  concerning  CALS  implementation,  the  Department  of  the 

Navy  (DoN)  has  directed  its  personnel  on  30  September  1994  that: 

The  Acquisition  Plan  (API  should  also  include  the  following 
statement,  applicable  for  the  competitive  System  Dem/Val,  Engineering 
and  Manufacturing  Development  (EMD),  Production  and  Deployment 
(P&D),  and  Operation  and  Support  (O&S)  efforts: 
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The  [XYZ]  project  intends  to  implement  CALS  and  Electronic 
Data  Interchange  (EDI)  initiatives  to  reduce  life  cycle  costs,  improve 
product  quality,  reduce  program  risk  and  reduce  the  schedule  of  the  design, 
development  and  production.  The  technical  information  required  in  support 
of  the  project  will  be  made  accessible  through  on  -line  contractor 
integrated  technical  information  (electronic)  services;  physical  delivery  of 
data  required  for  sustaining  support  activities  will  be  in  accordance  with 
approved  CALS  format  standards  and  specifications.  For  contract  data 
requirements  not  evaluated  as  cost-effectively  delivered  to  the  CALS 
standards/specifications,  delivery  will  be  in  mutually  agreeable  digital 
formats  The  digital  formats  for  all  data  users  and  user  systems  will  be 
determined  cooperatively  between  the  government  and  contractor  using  the 
Government  Concept  of  Operations  (GCO),  developed  by  the  government 
program  office,  as  the  basis  for  selection. 

The  draft  and  final  RFPs  will  incorporate  requirements  for  the  offer 
or  to  address  implementation  of  concurrent  engineering  and  digital 
delivery/electronic  access  of  program  technical  information.  Significant 
weighting  will  be  applied  to  the  CALS  and  EDI  elements  in  source 
selection  evaluation  (not  less  than  10  percent  of  the  total  evaluation/rating). 
Offerors  will  be  evaluated  on  their  ability  to  provide  integrated,  shared 
databases  environments  for  engineering  analysis,  design,  manufacturing  and 
logistic  processes;  and  their  use  of  CAD/CAM/CAE  methods,  product 
models/databases  and  simulation  tools  to  improve  product  design,  testing, 
manufacturing  and  support  system  development.  The  program  will 
integrate  specific  program  solutions  with  those  developed  by  DoD/DoN 
infrastructure  modernization  initiatives  and  will  implement,  where  value 
-effective,  joint  service  CALS  and  EDI  systems  for  the  creation, 
management  and  use  of  digital  technical  information. 
[Ref.  11:  pp.  3-3,  3-4] 


B.  IMPLEMENTATION  GUIDELINE:  MIL-HDBK-59B 

The  original  purpose  of  MIL-HDBK-59  was  to  provide  general  information  and 
detailed  application  guidance  for  contractually  implementing  CALS  requirements  in 
weapons  systems  and  related  equipment  procurements,  to  those  responsible  for  the 
acquisition  and  use  of  the  weapons  systems  technical  data.  [Ref.  18:  p.  62] 
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MIL-HDBK-59  (as  a  CALS  Implementation  Guide  and  the  superseding 
MIL-HDBK-59A)  was  developed  by  the  Department  of  Defense  with  the  assistance  of  the 
military  departments.  Federal  agencies,  and  industry,  and  is  approved  for  use  by  all 
Departments  and  Agencies  of  the  Department  of  Defense.  It  provides  information  and 
guidance  for  applying  the  CALS  strategy  to  the  acquisition,  management  and  use  of  digital 
data  in  support  of  defense  weapons  systems  and  equipment,  hereafter  referred  to  as 
'defense  systems'.  [Ref.  8] 

This  handbook  provides  information  and  guidance  for  applying  the  CALS  strategy 
to  the  acquisition,  management,  and  use  of  digital  data  in  accordance  with  (LAW)  DoD 
Instruction  (DoDI)  5000.2.  The  primary  focus  of  this  handbook  is  the  acquisition  of 
digital  data  products  and  information  services  in  support  of  defense  systems.  It  addresses 
1)  CALS  strategy;  2)  CALS  policy;  3)  acquisition  process  guidance;  4)  special 
considerations  for  existing  defense  systems;  and  5)  DoD  infrastructure  modemization- 
Joint  CALS  (JCALS).  [Ref.  8] 

MIL-HDBK-59  details  a  structured  approach  to  implementing  CALS 
requirements,  data  interchange  standards,  and  data  format  specifications.  Sections  2  and  3 
provide  guidance  to  acquisition  managers  on  the  CALS  strategy  and  CALS  policy. 
Section  4  provides  an  overview  for  applying  the  CALS  strategy  to  the  acquisition  process, 
including  development  of  Request  for  Proposal  (RFP)  and  Statement  of  Work  (SOW) 
language,  detailed  planning  guidance  for  development  of  the  CALS  Government  Concept 
of  Operations  (GCO),  and  the  Contractor's  Approach  to  CALS  (CAC).  Special 
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considerations  for  applying  CALS  to  existing  defense  systems  can  be  found  in  section  5. 
Infrastructure  consideration  issues  are  addressed  where  applicable  throughout,  while 
section  6  provides  an  overview  of  infrastructure  modernization  through  JCALS.  [Ref.  8] 

C.  STANDARDS  FOR  DOCUMENT  SPECIFICATION 

1.  Automated  Interchange  of  Technical  Information:  MIL-STD-1840B 
a.  Purpose 

MIL- STD- 1840 A,  Automated  Interchange  of  Technical  Information,  was 
originally  published  by  the  U.S.  Air  Force  on  11  September  1986.  Its  purpose  was  to 
standardize  the  digital  interface  between  organizations  necessary  for  the  logistic  support  of 
weapons  systems  throughout  their  life  cycle. 

MIL-  STD- 1 840B  supersedes  and  enhances  MIL- STD- 1840 A,  and  serves 
as  a  central  standard  for  the  CALS  environment.  MIL-STD-1840B  standardizes  formats 
for  the  exchange  of  digital  information  between  organizations  and/or  systems  to  facilitate 
the  development  and  logistic  support  of  defense  systems  throughout  their  entire  life  cycle. 

MDL-STD-1840B  further  refines  the  format  of  data  to  be  exchanged  in  the 
CALS  environment,  the  mechanisms,  and  parameters  of  those  mechanisms  required  for  the 
exchange  to  take  place.  Additionally,  MIL-STD-1840B  addresses  the  content  of 
electronic  product  data,  new  packaging  of  data  for  electronic  trade  business  transactions, 
and  electronic  product  data  technology. 
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The  M3L-STD-1840B  standard  formally  defines,  by  reference,  the 
configuration  and  structure  of  data  files  used  for  the  transfer  and  archival  of  technical  data 
in  digital  form.  It  clearly  defines  the  record  formats,  standardized  header  records,  contents 
of  the  files  used  for  exchange  of  data,  labeling  requirements  during  shipment,  protection, 
packaging,  and  the  marking  of  media.  Some  of  the  provisions  for  "protection"  of  media 
require  that  electromagnetically  inscribed  information  transfer  media  such  as  encoded 
magnetic  tapes  and  disks  be  protected  against  dirt,  moisture,  and  electrostatic  discharge 
damage  during  shipment.  [Ref.  1 1] 

b.  Typical  Applications 

The  MIL-STD-1840B  standard  is  designed  to  be  usable  for  all 
CALS-related  applications  where  information  can  be  prepared  and  received  as  ASCII 
(American  Standard  Code  for  Information  Interchange)  text  files,  product  definition  data 
files,  raster  image  files,  graphics  files,  or  contract  defined  data  files.  This  standard  is  not 
designed  to  be  usable  for  specific  applications,  but  is  not  restricted  in  any  way  in  its 
application. 

MIL-STD-1840B  is  intended  for  application  to  technical  information  which 
includes  product  data,  product  acquisition  and  implementation  data,  and  product  support 
data.  Product  data  includes  engineering  drawings  and  specifications,  as  well  as  new  and 
evolving  digital  data  protocols  which  provide  platform-independent  data  directly  usable  by 
a  variety  of  unrelated  computer  applications.  Product  acquisition  and  implementation  data 
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includes  parameters  and  data  necessary  to  manufacture  and/or  acquire  an  entire  defense 
system  Product  support  information  includes  training  and  maintenance  manuals, 
including  associated  illustrations,  necessary  to  the  maintenance  of  a  defense  system  in  a 
required  state  of  readiness.  The  scope  of  this  data  covers  the  entire  life  cycle  of  a  weapons 
system. 

MIL-STD-  1840B  further  provides  general  requirements  for  Technical 
Publication,  Product  Data,  and  Electrical/Electronic  Application  Data  File  document 
types.  The  Technical  Publications  document  type  includes  files  that  contain  MIL-M-28001 
SGML  (Standard  Generalized  Markup  Language),  Document  Type  Declaration  with  no 
text,  FOSI  (Formatting  Output  Specification  Instance),  SGML  text  entity,  MIL-D-28000 
IGES  (Initial  Graphics  Exchange  Specification),  MIL-R-28002  Raster,  MIL-D-28003 
CGM  (Computer  Graphics  Metafile),  PDL  (Page  Description  Language),  gray  scale  or 
color  illustration,  or  special  word  data.  The  Product  Data  document  type  includes  files 
that  represent  engineering  drawings  in  IGES  or  raster  formats  as  well  as  numerical  control 
manufacturing  and  3-dimensional  piping  data  files.  The  Electrical/Electronic  Application 
Data  Files  document  type  includes  files  that  contain  information  in  the  following  formats: 
Electronic  Design  Interchange  Format  (EDIF),  the  Very  High  Speed  Integrated  Circuit 
(VHSIC)  Hardware  Description  Language  (VHDL),  IGES  Electrical/Electronic 
application  data  files,  and  Institute  for  Interconnecting  and  Packaging  Electronic  Circuits 
(IPC). 
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In  any  typical  application,  the  hardware  and  software  must  prepare  files  for 
transfer  on  the  sending  system  by  adding  header  information  and  writing  files  to  the 
selected  media  type.  Hardware  and  software  on  the  receiving  system  must  process 
received  files  by  reading  the  files  from  the  selected  media  type  and  stripping  off  the  added 
header  information.  Media  to  be  sent  must  also  be  labeled,  protected,  packaged,  and 
marked  appropriately  prior  to  shipment  in  accordance  with  this  standard.  [Ref.  1 1] 


c.  Structure 

MIL-STD-1840B  is  composed  of  the  following  six  sections: 

•  Section  1:  SCOPE.  Defines  the  scope  of  M3L-STD-1840B  with 
respect  to  standardizing  the  exchange  of  digital  information  between 
organizations  or  systems. 

•  Section  2:  REFERENCED  DOCUMENTS.  Identifies  all  of  the 
documents  upon  which  MIL-STD-1840B  is  based  (See  Section  2.9  of 
this  overview). 

•  Section  3:  DEFINITIONS.  Defines  the  abbreviations  and  terms  used 
in  MIL-STD-1840B. 

•  Section  4:  GENERAL  REQUIREMENTS.  Specifies  the  general 
requirements  of  mandatory  declaration  files  as  well  as  the  specific 
standards,  specifications,  and  data  formats  required  for  data  files 
covered  by  this  standard  (See  section  2.2  of  this  overview). 

•  Section  5:  DETAILED  REQUIREMENTS.  Specifies  the  structure, 
contents,  media  options,  and  packaging  requirements  for  digital 
information  constituting  a  transfer  package.  This  section  fists  file 
naming  conventions  for  both  declaration  and  data  files  along  with  the 
header  records  these  files  require.  The  information  required  in  these 
records  include  identifiers  of  the  parent  file,  text  files,  and  data  files,  as 
well  as  destination  and  source  system  document  identifiers.  Packaging 
requirements  specified  by  MIL-STD-1840B  include  detailed 
instructions  for  labeling,  protecting,  marking,  and  packaging  the 
transfer  media  for  shipment. 
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•  Section  6:  NOTES.  Provides  information  which  is  helpful,  but  not 
mandatory.  [Ref.  11] 

d.  Advantages  of  Current  Standard 

MIL-STD- 1 840B,  a  standard  for  the  interchange  of  digital  technical  data, 
is  a  core  standard  for  the  CALS  environment.  In  addition  to  the  advantage  of  being 
required  for  the  delivery  of  CALS  data,  this  standard  has  the  advantage  of  having  an 
essential  function  that  facilitates  the  sharing  of  technical  data  within  and  among 
autonomous  organizations. 

This  standard  clearly  defines  the  mechanisms  for  exchanging  digital  data 
with  protocols  defined  in  other  CALS  specifications  (MJL-D-28000,  MEL-M-28001, 
MJL-R-28002,  and  MIL-D-28003).  The  reference  to  and  use  of  other  standards  and 
specifications  allows  this  standard  to  evolve  synchronously,  as  other  standards  and 
specifications  evolve,  taking  advantage  of  opportunities  presented  by  advances  in  current 
technologies,  or  to  effectively  utilize  new  technologies. 

MIL-STD- 1840B  contains  specific  detailed  instructions  for  using  9-track 
magnetic  tapes  as  a  medium  for  exchange  of  digital  data.  It  contains  flexible  provisions 
which  rely  on  agreements  between  sender  and  receiver  for  using  other  media  such  as 
diskettes,  WORM  (Write  Once  Read  Many-times)  optical  disks,  and  CD-ROM  (Compact 
Disk  Read  Only  Memory)  for  the  exchange  of  technical  data.  This  reliance  on  agreements 
provides  MIL-STD-1840B  with  the  advantage  of  accommodating  changing  user  needs  as 
well  as  being  able  to  adapt  to  new  requirements  and  guidelines. 
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An  additional  advantage  of  MEL-STD-1840B  is  that  it  clearly  defines  the 
formats,  standardized  header  records,  and  contents  of  files  used  for  the  exchange  of  data 
as  well  as  requirements  for  the  labeling,  protection,  packaging,  and  the  marking  of  media 
during  shipment.  The  standard  also  addresses  electronic  product  data,  new  packaging  of 
data  for  electronic  trade  business  transactions,  and  electronic  product  data  technology. 
[Ref.  11] 

e.  Vendor  Support 

MIL-STD-1840B  has  been  approved  for  use  by  all  agencies  of  the 
Department  of  Defense.  It  is  required  for  the  delivery  of  all  CALS  data.  This  military 
standard  specifies  other  standards  that  are  widely  supported  and  accepted  by  national  and 
international  normalization  organizations  alike,  providing  a  strong  foundation  for  user  and 
vendor  support. 

The  extent  of  use  of  MIL-STD-1840B  depends  upon  the  degree  of 
accepted  implementation  of  the  standards  of  interchange  which  it  specifies.  Additional 
information  can  be  obtained  about  users  and  vendors  who  are  implementing 
MIL-STD-1840B  as  a  part  of  their  implementation  of  these  CALS  standards  and 
specifications  by  reviewing  the  same  section  of  the  summaries  for  MIL-M-28001 
(SGML),  MIL-D-28000  (IGES),  MIL-R-28002  (Raster),  or  MIL-D-28003  (CGM).  [Ref. 
11] 
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2.  Digital  Representation  For  Communication  Of  Product  Data:  IGES 
Application  Subsets  and  IGES  Application  Protocols  (MIL-D-28000A) 

The  MIL-D-28000A  military  specification  defines  a  standard  for  product  definition 
data  formats.  Product  definition  data  consists  of  the  elements  required  to  define  a  product. 
It  includes  geometry,  topology,  relationships,  tolerances,  attributes,  and  features  necessary 
to  define  a  component  part  or  assembly  of  parts  for  the  purpose  of  design,  analysis, 
manufacture,  test,  and  inspection.  [Ref.  8] 

a.  Purpose 

MIL-D-28000A  is  the  military  specification  for  the  digital  representation  of 
product  definition  data  using  the  Initial  Graphics  Exchange  Specification  (IGES)  as 
specified  by  the  American  Society  of  Mechanical  Engineers  (ASME)  standard  Y14.26M 
(Digital  Representation  for  Communication  of  Product  Definition  Data).  MIL-D-28000A 
is  organized  into  five  classes  by  application  area  to  meet  the  general  delivery  needs  of 
products.  [Ref.  11] 

b.  Application  Subsets  and  Protocol 

MDL-D-28000A  specifies  five  classes  of  the  IGES  standard  (technical 
illustrations,  engineering  drawings,  electrical/electronics  applications,  numerical  control 
manufacturing,  and  3-D  piping)  as  opposed  to  the  entire  IGES  standard.  MIL-D-28000A 
subdivides  the  IGES  specification  because  IGES  is  large  and  complex,  with  different 
options  that  may  be  used  to  represent  the  same  Computer  Aided  Design  (CAD)  model 
entity. 
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The  first  four  classes  of  MIL-D-28000A  specify  the  entities  needed  for 
specific  application  subsets.  In  this  way  the  recipient  of  a  M3L-D-28000A  data  file  may 
specify  the  class  of  data  needed  without  becoming  an  expert  on  the  IGES.  The  only  other 
entities  allowed  in  the  file  are  "volunteer"  entities.  Restrictions  and  specific  requirements 
are  placed  on  volunteer  entities  so  that  the  CAD  system  that  receives  the  file  will  not  lose 
product  information  if  it  does  not  transfer  the  "volunteer"  entities. 

The  four  application  subsets  defined  within  MIL-D-28000A  are  described 
in  the  following  paragraphs: 

Class  I:  Technical  Illustrations  Application  Subset  The  Class  I 
application  subset  is  for  the  exchange  of  illustrations  for  technical  publications.  The 
emphasis  is  on  the  visual  appearance  of  the  illustrations,  not  on  the  functionality  of  the 
entities  within  the  class.  Class  I  is  a  two  dimensional  subset  with  limited,  non-geometric 
information  (such  as  subfigures). 

Class  II:  Engineering  Drawings  Application  Subset  The  Class  II 
application  subset  is  for  the  exchange  of  product  data  following  MDL-T-3 1000  (Technical 
Data  Packages,  General  Specification  for).  The  emphasis  is  on  completeness,  functionality 
of  the  drawing  model,  and  visual  equivalency  for  human  interpretation.  The  class  contains 
many  geometric  entities,  annotation  entities,  and  attributes  such  as  color  and  line  fonts, 
along  with  organizational  information  such  as  levels  and  subfigures.  The  geometric  entities 
in  this  class  are  three  dimensional,  though  two  dimensional  data  can  be  transferred  by 
placing  all  the  information  on  the  same  plane  within  the  sending  CAD  system. 


40 


Class  HI:  Electrical/Electronic  Applications  Subset.  The  Class  HI 
application  subset  is  for  the  exchange  of  product  data  for  electrical  and  electronic 
products.  The  emphasis  is  on  completeness  and  functionality  of  the  model  for  design, 
manufacturing,  and  testing.  Class  HI  supports  both  the  logical  product  representation  and 
the  physical  product  representation,  which  can  both  be  in  the  same  file.  The  logical 
representation  includes  netlists  and  schematics,  while  the  physical  representation  includes 
assembly  placement  and  pad  layouts.  Class  m  is  difficult  to  use  for  unambiguous  data 
exchange  without  further  restrictions  and  interpretations  applied  to  the  subset.  The 
IGES/PDES  Organization  (EPO)  Electrical  Applications  Committee  (EAC)  is  developing  a 
Layered  Electrical  Products  (LEP)  AP  for  the  representation  of  electrical  products.  The 
LEP  AP  is  currently  planned  to  be  a  replacement  for  MIL-D-28000  Class  HI. 

Class  IV:  Geometry  for  NC  Manufacturing  Application  Subset  The 
Class  IV  application  subset  is  for  the  exchange  of  product  data  for  manufacturing  by 
numerical  control.  The  emphasis  is  on  the  completeness  and  functionality  of  the  part 
model.  Geometry  data  is  either  2-D  wireframe,  for  profiles  or  sheet  metal,  or  a  3-D 
wireframe  model  for  multi-axis  machining.  Precision  and  accuracy  on  the  wireframe  and 
surface  geometry  must  be  maintained,  as  well  as  first  order  continuity.  Geometry  and  Text 
form  the  majority  of  the  data  for  this  class.  [Ref.  1 1] 

An  Application  Protocol  (AP)  is  a  way  to  transfer  defined  product  data 
through  IGES.  An  AP  documents  the  user  requirements  for  an  application  in  a  graphical 
model  called  an  Application  Reference  Model  (ARM). 
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Class  V:  3-D  Piping  Application  Protocol.  The  Class  V  application 
protocol  is  for  the  exchange  of  product  data  for  3-D  piping  system  models,  but  not  piping 
drawings  or  internal  details  of  equipment.  The  Class  V  AP  conveys  shape  and  location, 
connectivity,  material  characteristics,  information  about  elements  in  the  piping  system  and 
the  piping  system  as  a  whole.  The  Class  V  provides  information  for  the  core  requirements 
of:  interference  analysis,  connectivity  checks,  basic  parts  lists,  graphics  presentation,  basic 
piping  isometrics,  pipe  bending  instructions,  and  limited  piping  redesign.  This  Class  V  AP 
is  not  intended  for  general  purpose  CAD  system,  but  for  3-D  piping  system  apphcations 
only.  Both  the  sending  and  receiving  systems  must  support  the  specific  3-D  piping  system 
application  and  the  Class  V  3-D  Piping  Application  Protocol  for  meaningful  exchange. 
[Ref.  11] 

c.  Vendor  Support 

The  IGES  specification  has  gained  support  from  CAD  system  vendors. 
Most  CAD  systems  have  some  type  of  IGES  translator,  and  even  some  non-CAD  systems, 
such  as  Interleaf®  (an  electronic  publications  system),  support  the  IGES  specification. 
Support  for  MIL-D-28000  (i.e.,  the  subsets)  is  not  as  widespread  as  support  for  the  full 
IGES  standard.  The  greatest  stated  support  of  the  MIL-D-28000  subsets  derives  from 
commercial  flavoring  software  and  syntax  checking  software.  MIL-D-28000  Class  n, 
engineering  drawings,  is  the  most  commonly  supported  class,  followed  by  MIL-D-28000 
Class  I,  technical  illustrations.  Presently,  Intergraph  has  a  MIL-D-28000  Class  V 
translator  under  development.  [Ref.  1 1] 
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3.  Standardized  Generalized  Markup  Language  (SGML)  MIL-M-28001B 


The  MIL-M-28001B  specification  defines  a  standard  for  preparation  of  textual 
technical  information  using  the  SGML.  Data  prepared  in  conformance  to  these 
requirements  will  facilitate  the  automated  storage,  retrieval,  interchange,  processing,  and 
presentation  of  technical  information  from  heterogeneous  data  sources.  [Ref.  8]  In 
essence,  the  CALS  standard  MIL-M-28001B  represents  the  DoD  implementation  of  the 
international  standard  ISO  8879  "Standard  Generalized  Markup  Language  (SGML)". 
[Ref.  11] 

a.  Purpose 

The  CALS  SGML  standard  defines  both  a  methodology  and  a  high  level 
computer  language  for  document  representation.  It  provides  a  coherent  and  unambiguous 
grammar  and  syntax  for  describing  whatever  objects  a  user  chooses  to  identify  within  a 
document,  regardless  of  the  type  of  document  or  the  nature  of  the  document's  text,  and 
provides  a  formal  markup  procedure  independent  of  system  and  output  environments. 
[Ref.  11] 

b.  Document  Type  Definition  (DTD) 

Document  definition  of  structure  or  content  in  terms  of  "elements",  their 
"attributes",  "entities",  and  other  components,  is  a  called  "Document  Type  Definition 
(DTD)".  A  DTD  defines  the  structure  or  content  of  a  specific  class  of  document  objects. 
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"SGML  markup"  (or  an  "SGML  document  instance")  consists  of 
unformatted  text  with  inserted  SGML  "tags,"  or  tokens,  which  correspond  to  the  elements 
and  attributes  of  the  DTD.  These  tags  identify  elements  of  the  text  (e.g.,  titles, 
paragraphs,  tables,  and  footnotes)  defined  in  the  document's  DTD.  The  "marked  up" 
document  (SGML  document  instance)  can  then  be  "parsed"  using  special  error  editing 
software  to  determine  if  the  document's  tagging  conforms  to  the  DTD.  [Ref.  1 1] 

c.  Output  Specification 

In  order  to  format  an  SGML  source  file,  associated  structural  protocol 
information  must  be  provided.  This  information  must  define  formatting  characteristics 
such  as  page  model,  font  and  family  characteristics,  point  size,  indenting,  etc.  In  addition, 
these  formatting  characteristics  must  be  responsive  to  certain  SGML  tags.  For  example,  a 
"paragraph"  tag  may  trigger  a  change  in  a  line  leading  or  a  "chapter  title"  tag  may  trigger 
"bolding"  and  "center"  functions  within  paragraphs.  The  Electronic  Publishing  Committee 
of  the  CALS  Industry  Standards  Working  Group  formed  a  MIL-M-28001  Output 
Specification  Ad  Hoc  Group  to  develop  a  standard  language  for  providing  associated 
formatting  information  for  SGML  instances.  It  was  decided  to  use  SGML  itself  for  this 
purpose  and  provide  the  associated  formatting  information  in  the  form  of  an  "Output 
Specification"  (OS)  DTD.  [Ref.  11] 
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d.  Vendor  Support 


The  vendor  community  is  aware  of  the  evolving  nature  of  MIL-M-28001. 
Several  vendors  are  waiting  until  the  standard  is  finalized,  while  other  vendors  are 
undertaking  full  implementations.  A  large  vendor  community  is  represented  on  the 
Electronic  Publishing  Committee.  For  the  CALS  environment,  vendors  supporting 
MEL-M-28001  should  not  "hard-code"  their  systems  to  process  only  a  single  DTD  or 
FOSI.  Inevitably,  most  users  will  be  processing  a  variety  of  technical  publications  which 
must  conform  to  multiple  DTDs  and  will  require  a  system  that  can  be  configured  to  adapt 
to  new  and  changing  requirements  as  they  arise.  [Ref.  11] 

4.  Raster  Graphics  Representation  In  Binary  Format  (MEL-R-28002) 

This  military  specification  was  originally  conceived  to  fill  the  need  for  national  and 
international  standards  for  the  storage  and  exchange  of  large  engineering  drawings  as 
raster  graphics  files.  Now  known  as  a  standardization  document,  its  current  version  is 
based  on  ISO  standards  and  the  Consultative  Committee  for  International  Telegraph  and 
Telephone  (CCITT)  recommendations.  [Ref.  4] 

a.  Purpose  and  Applicability 

The  Mil  -R-28002  specification  establishes  requirements  for  a  standard 
interchange  file  format  and  raster  encoding  scheme  for  raster  data.  This  specification 
identifies  the  requirements  to  be  met  when  raster  data  represented  in  digital,  binary  format 
is  delivered  to  the  Government. 
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Raster  graphics  involves  the  digital  processing,  storage,  exchange  and 
reproduction  of  images.  This  technology  supports  the  binary  representation  of  a 
two-dimensional  image  as  an  array  of  picture  elements,  also  known  as  pels.  Each  pel  of 
the  array  contains  information  about  that  portion  of  the  image.  This  information  may 
include  its  lightness,  darkness,  gray-level  and  color.  The  quality  of  the  image  depends 
directly  on  the  density  of  pels  within  the  array,  also  known  as  resolution  density  or  pel 
transmission  density.  High  resolution  density  provides  a  high  quality  image,  but  at  the 
expense  of  higher  storage  costs.  Data  compression,  in  which  an  encoding  scheme  is  used 
to  represent  redundant  data  bits  of  information,  can  alleviate  this  storage  problem  to  some 
extent.  MIL-R-28002  restricts  such  compression  to  Group  4  encoding  as  defined  in 
Consultative  Committee  on  Telegraph  and  Telephone  (CCITT)  Recommendation  T.6  in 
order  to  conform  to  developing  industry  standards. 

MIL-R-28002  permits  two  types  of  digital  representation  of  raster  data, 
referred  to  as  Type  I  and  Type  II  in  the  specification.  The  Type  I  file  format  is  used  for 
raster  data  contained  in  a  single  monolithic  block  of  compressed  data  and  is  called  untiled 
raster  data.  The  Type  II  file  format  is  an  Open  Document  Architecture  (ODA)  document 
(as  specified  by  ISO  8613  ODA)  conforming  to  a  special  application  profile  for  raster 
images.  Type  II  may  be  tiled  raster  data  or  may  consist  of  a  single  compressed  block  of 
data  as  in  Type  I,  but  with  all  ODA  parameters  and  data  structuring  included. 

Type  I  raster  data  interchange  is  intended  to  be  used  in  procuring  data  for 
systems  that  only  utilize  untiled  raster  data  representations.  Examples  of  such  systems 
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include  typical  technical  documentation  systems,  the  Air  Force  Engineering  Data 
Computer-Assisted  Retrieval  System  (EDCARS)  and  the  Army  Digital  Storage  and 
Retrieval  Engineering  Data  System  (DSREDS).  A  set  of  graphics  attributes  specifying  the 
details  necessary  for  processing  and  reproducing  the  image  must  be  included  in  a  header 
record  at  the  beginning  of  the  raster  file.  These  attributes  include  the  size  of  the  original 
image,  scanning  resolution,  image  orientation  (portrait  or  landscape),  starting  position  on 
the  page,  and  spacing  between  pels  and  lines  containing  the  pels.  These  attributes  are  used 
in  reproducing  the  image  and  apply  to  both  Type  I  and  Type  II  raster  data  files. 

Type  II  raster  data  interchange  is  intended  to  be  used  in  procuring  data  for 
systems  that  need  the  flexibility  to  use  tiled  or  a  mixture  of  tiled  and  untiled  raster  data 
representations.  Tiled  representations  are  best  applied  in  systems  handling  large  format 
drawings  or  illustrations  typically  associated  with  engineering  design.  The  subdivision  of  a 
drawing  into  tiles  allows  the  use  of  only  those  portions  of  an  image  required  at  a  given 
time  by  the  application.  This  can  result  in  reduced  requirements  for  workstation  memory 
and  display.  Attributes  required  for  Type  I  are  also  required  for  Type  II  data  and  are 
encoded  in  the  ODA  data  stream  as  specified  by  the  ODA  Raster  DAP  (as  explained 
below).  For  Type  II  data,  additional  attribute  information  must  be  included  to  cover  the 
size  of  each  tile,  the  number  of  tiles  in  the  array  (image),  the  method  of  tile  ordering,  and 
the  method  of  tile  coding.  This  information  is  stored  in  the  header  record  of  an  image  file 
during  the  scanning  process  and  is  essential  for  reproducing  the  image.  [Ref.  1 1] 


47 


b.  Advantages  of  Current  Specification 


MIL-R-28002  reflects  the  intent  of  the  OSD  to  use  existing  and  emerging 
international  standards  as  the  basis  for  implementation.  The  ODA  standard  provides  for 
storage  of  complex  documents  containing  graphics  and  textual  information  and  production 
of  compound  documents  using  facsimile  technology.  ODA  was  cited  for  Type  II  raster 
data  specification  in  an  effort  to  ensure  that  raster  image  data  specification  efforts  align 
with  evolving  international  raster  imaging  standards  while  promoting  interop  erability  with 
other  raster  data  formats  used  in  the  open  document  architecture  standard.  [Ref.  11] 

c.  Vendor  Support 

The  Electronic  Imaging/Compression  Committee  of  the  Association  for 
Information  and  Image  Management  (AIIM)  has  developed  a  standard:  ANSI/AHM 
MS53  1993,  the  Standard  Recommended  Practice  -  File  Format  for  Storage  and 
Exchange  of  Images  -  Bi-Level  Image  File  Format:  Part  1,  that  specifies  file  formatting 
for  exchange  of  bi-level,  electronic  images.  MS 5 3  is  considered  a  subset  of  the  ODA 
Raster  DAP,  but  it  does  not  allow  for  the  tiling  of  raster  images.  This  standard  was 
developed  to  encourage  the  use  of  ODA  by  the  United  States  image  technology 
community  and  to  provide  a  much  needed  standard  bi-level  image  file  format.  It  is  seen  as 
an  introductory  tool  for  users  and  implementors  of  ODA,  ASN.  1  and  ODA  Raster  DAP 
applications  requiring  MIL-R-28002  Type  II  untiled  data.  MS53  is  AIIM's  attempt  at  a 
"cookbook"  approach  for  exchanging  bi-level  electronic  images  using  ODA  with  ASN.  1 
encoding. 


48 


5.  Digital  Representation  For  Communication  Of  Illustration  Data: 

Computer  Graphics  Metafile  (CGM)  (MIL-D-28003) 

Military  specification,  MIL-D-28003,  "Digital  Representation  of  Illustration  Data: 
Computer  Graphics  Metafile  (CGM)",  specifies  an  application  profile  of  the  International 
and  U.S.  standards  for  CGM  and  certain  specific  additional  requirements.  The  Computer 
Graphics  Metafile  standard  is  a  published  International  Standard  (ISO/IEC  8632),  a 
Federal  Information  Processing  Standard  (FIPS  128),  and  has  been  adopted  by  the 
American  National  Standard  Institute  (ANSI).  CGM  is  being  developed  and  maintained 
through  a  coordinated  effort  of  ISO  SC24  and  ANSI  X3H3.  U.S.  and  international 
standards  are  identical.  [Ref.  1 1] 

a.  Purpose  and  Applicability 

The  overall  intent  of  the  CGM  standard  is  to  provide  the  lowest  level  of 
drawing  functionality  required  to  capture  and  reproduce  a  picture  in  a  way  that  is  portable 
across  non-aligned  applications  and  devices.  CGM  specifies  two-dimensional  graphics 
data  interchange  in  a  file  format  that  can  be  created  independently  of  device  requirements 
and  translated  into  formats  required  by  specific  output  devices,  graphics  systems,  and 
computer  systems. 

A  metafile  is  a  device-independent,  application-independent  storage  format 
for  the  exchange  of  data  that  makes  up  a  picture  ("picture  data").  Metafile  definition  in 
ISO/IEC  8632  includes  a  specification  of  output  primitives  and  attributes  that  may  be  used 
to  compose  an  illustration  represented  by  an  intentionally  under-specified  semantics 
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(meaning).  This  was  done  to  accommodate  a  wide  range  of  existing  systems,  and  to  make 
the  standard  more  adaptable  to  the  requirements  of  diverse  applications  and  users.  If  the 
application  software  is  directed  to  store  a  picture  on  a  metafile,  it  has  to  write  all  of  the 
information  required  for  reassembly  into  a  file.  Software  that  performs  CGM  writing 
actions  is  called  the  "generator".  Software  that  can  read  a  metafile  back  into  an 
application  and  reconstruct  the  intended  image  is  called  an  interpreter. 

A  "profile"  addresses  implementation  conformance  requirements  for  the 
generator  and  interpreter.  For  generators,  the  graphical  characteristics  of  the  picture  are 
mapped  onto  a  set  of  CGM  elements  which  define  the  images  within  the  accuracy  and 
latitude  defined  by  the  implementation  requirements  in  the  profile.  For  interpreters,  the 
graphical  characteristics  of  the  CGM  elements  are  rendered  into  a  graphical  image  or 
picture  within  the  latitude  defined  by  the  implementation  requirements  set  forth  in  the 
profile.  Without  a  profile,  one  can  only  address  the  syntactical  correctness  of  the  data 
stream  With  a  profile,  one  can  address  and  test  that  the  picture  is  correct.  Profiles 
provides  a  way  of  standardizing  and  publicly  specifying  the  options  that  a  vendor  supports 
and  how  they  are  to  be  supported.  [Ref.  1 1] 

b.  Advantages 

The  CGM  contains  device-independent,  digitally- encoded  vector  and  raster 
graphics  data.  CGM  files  are  easily  transferred  and  displayed  on  a  wide  variety  of 
hardcopy  devices  (dot-matrix,  ink-jet,  electrostatic,  and  laser  printers,  pen  plotters,  and 
film  cameras).  CGM  files  can  also  be  easily  previewed  on  an  extensive  range  of  softcopy 
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terminals.  In  comparison  to  Raster,  CGM  is  easily  modifiable,  generally  of  much  smaller 
size,  and  not  dependent  upon  resolution  of  the  output  device.  CGM  compares  to  IGES 
(2-D  data),  CGM  is  faster  to  interpret  and  display,  and  again  more  compact.  The  selection 
of  which  of  the  CALS  graphic  standards  (raster,  IGES,  or  CGM)  that  best  fits  the 
application,  should  be  the  result  of  the  thorough  examination  of  the  processes  involved  in 
the  application.  [Ref.  1 1] 

c.  Vendor  Support 

This  standard  associated  with  its  Application  Profile  is  considered  a  subset 
of  the  international  and  national  CGM  standard.  Many  vendors  who  claim  CGM  standard 
conformance,  do  not  completely  conform  with  MIL-D-28003A  because  of  the  lack  of 
Application  Profile  details  necessary  for  use  with  CALS  applications.  Currently  six 
software  vendors  (Ashton- Tate,  Computer  Support,  Lotus  Development,  Micrografx, 
Hewlett-Packard,  and  Software  Publishing)  offer  applications  that  can  import  and  export 
CGM  files  conforming  to  MIL-D-28003A.  Numerous  other  vendors  offer  applications 
that  can  either  import  or  export  CGM  files  or  can  both  import  and  export  CGM  files,  but 
only  in  conformance  with  the  previous  version  of  this  specification.  DoD  organizations 
planning  to  use  a  drawing  application  for  CALS  compliant  illustrations  should  be  certain 
that  the  application  explicitly  conforms  with  the  import  and  export  requirements  of 
MEL-D-28003A.  [Ref.  4] 
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D.  STANDARDS  FOR  INTERNETWORKING 


The  resources  of  a  single  network  are  often  inadequate  to  meet  user's  needs. 
Because  networks  that  might  be  of  interest  exhibit  so  many  differences,  it  is  impractical  to 
consider  merging  them  into  a  single  network.  Rather,  what  is  needed  is  the  ability  to 
interconnect  various  networks  so  that  any  two  stations  on  any  of  the  constituent  networks 
can  communicate  with  one  another. 

An  interconnected  set  of  networks  may  appear  simply  as  a  larger  network. 
However,  if  each  of  the  constituent  networks  retains  its  identity,  special  mechanisms 
(known  as  communications  protocols)  are  needed  for  communicating  across  multiple 
networks.  The  entire  configuration  of  internetworked  networks  is  often  referred  to  as  an 
internet,  and  each  of  the  constituent  networks  as  a  subnetwork.  [Ref.  19:  p.  471] 

According  to  the  JCALS  plan,  about  250  sites  and  contractors  should 
communicate  between  each  other  across  the  internet.  In  the  MIL-HDBK-59A,  DoD 
described  three  telecommunication  options  in  the  current  environment:  contractor-specific 
network  architecture,  OSI  compatible  network  architectures,  and  Transmission  Control 
Protocol/Intemet  Protocol  (TCP/IP)-based  Defense  Data  Network  (DDN)  architectures. 
[Ref.  17:  p.  177]  Of  these  three  network  architectures,  this  section  will  present  last  two 
architectures  as  options  because  of  their  popularity  and  open  networking  capabilities. 
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1.  Open  Systems  Interchange  (OSI) 


a.  Background 

OSI  protocols  have  been  developed  by  international  standards 
organizations,  primarily  the  International  Organization  for  Standardization  (ISO)  and  the 
Consultative  Committee  on  International  Telephone  and  Telegraph  (CCITT). 

As  the  use  of  computer  communications  and  computer  networking 
proliferate,  a  one-at-a-time  special-purpose  approach  to  communications  software 
development  is  too  costly  to  be  acceptable.  The  only  viable,  cost-effective  alternative  for 
computer  vendors  is  to  adopt  and  implement  a  common  set  of  conventions.  For  this  to 
happen,  a  set  of  international  or,  at  least  national,  standards  must  be  promulgated  by 
appropriate  organizations.  [Ref.  19:  p.  436] 

The  International  Organization  for  Standardization  (ISO),  the  Consultative 
Committee  on  International  Telephone  and  Telegraph  (CCITT),  and  other  standards 
formulation  bodies  have  adopted  a  seven-level  OSI  Reference  Model  for  guiding  the 
development  of  international  standards  for  networks  of  computers.  It  is  called  a  "reference 
model"  because  it  only  recommends  the  functions  to  be  performed  in  each  of  seven  layers. 
The  model  does  not  specify  detailed  standards  for  each  layer.  Those  are  left  up  to 
individual  standards  bodies  in  adopting  countries.  [Ref.  20:  p.  188] 

The  term  Open  Systems  Interconnection  (OSI)  qualifies  for  the  exchange 
of  information  among  systems  that  are  "open"  to  one  another  for  this  purpose  by  virtue  of 
their  mutual  use  of  the  applicable  standards.  Hwever,  the  fact  that  a  system  is  open  does 
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not  imply  any  particular  systems  implementation,  technology,  or  means  of  interconnection, 
but  refers  to  the  mutual  recognition  and  support  of  applicable  standards.  [Ref.  19:  p.  436] 

b.  Concepts 

A  widely  accepted  structuring  technique,  and  the  one  chosen  by  ISO,  is 
"layering. "  Communications  functions  are  partitioned  into  a  vertical  set  of  layers.  Each 
layer  performs  a  related  subset  of  functions  required  to  communicate  with  another  system. 
Layering  relies  on  the  next  lower  layer  to  perform  increasingly  more  primitive  functions 
and  to  conceal  the  details  of  those  functions.  At  the  same  time,  it  provides  services  to  the 
next  higher  layer.  Ideally,  layers  should  be  defined  so  that  changes  in  one  layer  do  not 
require  changes  in  preceding  or  succeeding  layers.  Thus  we  have  decomposed  one 
problem  into  a  number  of  localized,  more  manageable  subproblems. 

The  task  of  the  ISO  subcommittee  was  to  define  a  set  of  layers  and  the 
services  to  be  performed  by  each  layer.  The  partitioning  should  group  functions  logically, 
should  have  enough  layers  to  make  each  layer  manageably  small,  but  should  not  have  so 
many  layers  that  the  processing  overhead  imposed  by  the  aggregation  of  layers  is 
burdensome. 

The  attractiveness  of  the  OSI  approach  is  that  it  promises  to  solve  the 
heterogeneous  computer  communications  problem.  Two  systems,  no  matter  how 

different,  should  be  able  to  communicate  effectively  if  they  have  the  following  in  common: 

•  They  implement  the  same  set  of  communications  functions. 
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•  These  functions  are  organized  into  the  same  set  of  layers.  Peer  layers 
must  provide  the  same  functions,  but  note  that  it  is  not  necessary  that 
they  provide  them  in  die  same  way. 

•  Peer  layers  must  share  a  common  protocol. 

The  OSI  model,  by  defining  a  seven-layer  architecture,  provide  a 
framework  for  defining  these  standards.  [Ref.  19:  pp.  437-441] 

c.  OSI  in  the  CALS 

OSI  compatibility,  the  telecommunications  technology  that  industry  as  well 
as  government  is  moving  rapidly  to  implement,  is  cited  as  one  of  the  options  for  CALS 
telecommunications  in  MIL-HDBK-59A.  Federal  Information  Processing  Standards 
Standard  Number  146  (FEPS  146)  adopts  the  Government  Open  Systems  Interconnection 
Profile  (GOSIP)  Version  1  for  government  use.  GOSEP  defines  a  common  set  of  data 
communications  protocols  which  enable  computer  systems  developed  by  different  vendors 
to  interoperate  and  exchange  data.  GOSIP  version  1  includes  requisite  information  for 
acquisition  of  the  OSI  FTAM  (File  Transfer  and  Access  Management)  and  VT  (Virtual 
Terminal)  applications  as  well  as  the  various  lower  layers  of  protocol  to  support  them. 
This  suite  of  communications  protocols  include  the  most  popular  physical  media  including 
token  ring,  broadband,  and  Ethernet.  [Ref.  17:  pp.  178] 

MIL-HDBK-59A  emphasis  also  that  OSI  should  be  the  sole,  mandatory, 
interoperable  protocol  suite  for  new  procurements  involving  new  Automated  Information 
Systems  (AISs)  or  major  upgrades  to  existing  AISs,  including  network  services. 
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2.  TCP/IP-based  DDN 


a.  TCP/IP  Background 

Despite  of  predating  of  TCP/IP  from  OSI  and  far  more  implementation  and 
practical  experience,  little  attention  has  been  given  to  TCP/IP.  TCP/IP  is  an  outgrowth  of 
the  development  of  Advanced  Research  Project  Agency  computer  NETwork  (ARPANET) 
and  the  Defense  Data  Network.  Whereas  the  OSI  architecture  is  intended  to  guide  the 
future  development  of  protocols,  it  is  the  experience  already  gained  in  the  development 
and  use  of  protocols  within  ARPANET  that  has  led  to  this  communications  architecture. 

Both  OSI  and  TCP/IP  deal  with  communications  among  heterogeneous 
computers.  Both  are  based  on  the  concept  of  communications- specific  protocol 
architectures  and  have  many  similarities.  However,  there  are  philosophical  and  practical 
differences  between  the  OSI  model  and  the  TCP/IP  model.  [Ref.  19:  p.  451] 

b.  Characteristics 

The  DoD  has  issued  standards  for  a  set  of  communications  protocols.  Its 
motivations  are  similar  to  those  of  the  ISO  and  many  other  computer  systems  customers. 
DoD  needs  to  have  efficient,  cost-effective  communications  among  heterogeneous 
computers.  There  are  three  reasons  why  the  DoD  has  chosen  to  develop  its  own  protocols 
and  architectures  rather  than  adopt  evolving  international  standards.  These  are  explained 
as  follows:  1)  The  DoD  protocols  were  specified  and  have  enjoyed  extensive  use  prior  to 
ISO  standardization  of  alternative  protocols.  Because,  at  the  time  of  creation,  the  DoD 
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needs  were  immediate,  it  was  deemed  impractical  to  wait  for  the  ISO  protocols  to  evolve 
and  stabilize.  2)  DoD-  specific  communications  requirements  have  a  major  impact  on  the 
design  of  industry-accepted  protocols  and  architectures.  These  concerns  have  not  been 
uppermost  in  the  minds  of  the  ISO  developers,  and  predictably  are  not  reflected  in  the  OSI 
model.  3)  Philosophic  differences  exist  between  perceived  DoD  and  industry  requirements 
concerning  the  appropriate  nature  of  communications  architectures  and  protocols. 
[Ref.  19:  p.  451] 

The  first  reason  is  self-explanatory.  The  second  reason  is  the  specific  DoD 
requirements,  many  of  which  are  also  relevant  in  other  contexts,  such  as  survivability,  and 
include  availability,  security,  network  interoperability,  and  the  ability  to  handle  surge 
traffic.  The  third  reason  is  best  explained  by  examining  the  differences  between  TCP/IP 
and  the  OSI  model.  There  are  four  fundamental  differences: 

1)  The  concept  of  hierarchy  versus  layering.  The  TCP/IP  protocol 
recognizes  that  the  task  of  communications  is  too  complex  and  too  diverse  to  be 
accomplished  by  a  single  unit.  Therefore,  the  task  is  broken  up  into  modules  or  entities 
that  may  communicate  with  peers  in  another  system  One  entity  within  a  system  provides 
services  to  other  entities  and,  in  turn,  utilizes  the  services  of  other  entities.  The  OSI  model 
is  based  on  similar  reasoning,  but  takes  it  one  step  further.  The  next  step  is  recognition  of 
protocols  at  the  same  level  of  the  hierarchy  that  have  certain  features  in  common.  This 
yields  the  concept  of  rows,  or  layers,  and  the  attempt  to  describe  in  an  abstract  fashion 
which  features  are  held  in  common  by  the  protocols  within  a  given  row. 
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2)  The  importance  of  internetworking.  A  historical  difference  between 
the  TCP/IP  and  OSI  models  is  the  importance  that  TCP/EP  places  on  internetworking. 
Internetworking  occurs  when  two  communicating  systems  do  not  attach  to  the  same 
network.  Thus  transferred  data  must  traverse  at  least  two  networks,  usually  through  an 
interface  router  known  as  a  "gateway."  Both  the  initiating  and  receiving  networks  may  be 
quite  dissimilar.  The  requirement  for  internetworking  has  led  to  the  development  of  an 
Internet  Protocol.  Such  a  protocol  was  not  originally  given  a  place  within  the  OSI  model. 
The  current  OSI  document  makes  brief  reference  to  the  possibility  of  networks  in  tandem, 
and  an  internet  protocol  has  emerged  as  sublayer  of  the  network  layer  (layer  3).  This  is  not 
a  clean  solution,  but  it  is  not  the  only  one  possible  within  the  seven-layer  architecture. 

3)  The  utility  of  connectionless  services.  A  connectionless  service  is  one 
in  which  data  are  transferred  from  one  entity  to  another  without  the  prior  mutual 
construction  of  a  connection.  TCP/IP  places  equal  importance  on  connectionless  and 
connection-oriented  services,  whereas  the  OSI  model  is  couched  solely  in  terms  of 
connection- oriented  services.  It  is  expected,  however,  that  further  versions  of  the  OSI 
model  will  incorporate  connectionless  services. 

4)  The  approach  to  management  functions.  A  final  difference  between 
the  TCP/IP  and  OSI  models  is  the  way  in  which  various  management-related  functions  are 
treated. 

The  concept  of  management  functions  seem  not  to  meld  well  with  the  OSI 
model,  partly  because  these  are  mostly  connectionless  services,  partly  because  there  is  no 
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"place"  for  them.  TCP/IP  does  not  preclude  this  approach,  rather  it  goes  further.  Within 
this  architecture,  a  uniform  approach  is  taken  to  many  of  these  functions  and  they  are 
provided  by  protocols  that  can  best  be  described  as  "session  layer"  protocols.  This 
description  reflects  the  fact  that  these  protocols  make  use  of  transport  services. 
[Ref.  19:  pp.  451-454] 

c.  Architecture 

The  TCP/IP  architecture  is  based  on  a  view  of  communication  that  involves 
three  agents  :  processes,  hosts,  and  networks.  Processes  are  the  fundamental  entities  that 
communicate  between  initiators  and  recipients.  Processes  execute  on  hosts,  which  can 
often  support  multiple  simultaneous  processes.  Communication  between  processes  takes 
place  across  networks  to  which  the  hosts  are  attached.  These  three  concepts  yield  a 
fundamental  principle  of  TCP/IP:  the  transfer  of  information  to  a  process  can  be 
accomplished  by  first  getting  it  to  the  host  in  which  the  process  resides  and  then  getting  it 
to  the  process  within  the  host.  With  this  in  mind,  the  DPA  organizes  TCP/IP  protocols 
into  four  layers: 

•  The  network  access  layer  contains  those  protocols  that  provide  access 
to  a  communication  network.  Protocols  at  this  layer  exist  between  a 
communications  node  and  an  attached  host  or  its  logical  equivalent. 

•  The  internet  layer  consists  of  procedures  required  to  allow  data  to 
traverse  multiple  networks  between  hosts. 

•  The  host-host  layer  contains  protocol  entities  with  the  ability  to  deliver 
data  between  two  processes  on  different  host  computers. 
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•  The  process/application  layer  contains  protocols  for  resource  sharing 
(e.g.,  computer-to-computer)  and  remote  access  (e.g.,  terminal-to- 
computer).  [Ref.  19:  pp.  455-456] 

d.  DDN  in  CALS 

DDN  is  mentioned  as  a  CALS  telecommunication  option  in  the 
MIL-HDBK-59A.  Because  the  DDN  is  a  DoD  network,  sized  to  support  defense 
requirements  within  available  funding,  the  acquisition  manager  must  provide  sponsorship 
for  defense  contractor  nodes,  and  must  satisfy  defense  Communications  Agency 
requirements  to  justify  and  schedule  connection  to  the  network.  The  DDN  is  currently 
based  on  TCP/IP  standards  which  are  widely  supported  in  government  and  industry  with 
many  commercial,  off-the-shelf  products.  However,  the  DoD  has  committed  to 
accompany  industry  in  it's  transition  to  Open  System  Interconnection  (OSI)  compatible 
products,  implemented  through  new  standards  such  as  the  Government  OSI  profile 
(GOSIP).  [Ref.  17:  pp.  178] 

E.  EC/EDI 

1.  Background 

The  concept  of  EC/EDI  started  over  30  years  ago.  During  the  1960s,  the 
Transportation  Data  Coordinating  Committee  (TDCC)  of  the  United  States  became 
concerned  about  the  strangling  effect  of  paperwork  on  the  transportation  industry.  In 
1975,  the  TDCC  published  the  first  set  of  rules  for  EDI,  many  of  which  still  apply.  At  that 
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time,  computer  hardware,  software,  and  networks  were  not  capable  of  supporting  these 
new  business  procedures.  In  1979,  the  American  National  Standards  Institute  (ANSI) 
approved  TDCC's  approach  to  EDI  access  and  use,  as  embodied  in  the  ANSI  X12 
standard.  Since  then,  the  ANSI  X12  committee  has  generated  over  20  cross-industry 
transaction  data  format  variations  on  the  basic  theme  to  accommodate  unique  situations  in 
diverse  business  areas.  [  Ref.  21:  p.  3] 

2.  Definitions 

Electronic  Data  Interchange  (EDI)  is  the  intercompany,  computer-to-computer 
exchange  of  business  documents  in  standard  electronic  data  formats.  Transaction  data  is 
transmitted  from  the  sending  company’s  application  to  the  receiving  company's  application 
without  human  intervention.  Transactions  (also  called  transaction  sets)  include  invoices, 
shipping  schedules,  advance  ship  notices,  court  filings,  bills  of  lading,  and  purchase  orders. 
These  are  transformed  to  a  standard  data  format  and  electronically  transferred  between 
trading  partners  without  utilizing  hard-copy  or  re-keying  information.  Standard  transaction 
sets  are  approved  by  ANSI  in  the  X12  standard.  [Ref.  21:  p.  3] 

Electronic  Commerce  (EC)  includes  EDI,  but  recognizes  the  need  for  inter¬ 
personal  (human-to-human)  communications.  Of  the  transfer  activities  that  aid  in 
communications  technologies,  EC  is  significantly  broader  than  EDI.  [Ref.  22:  p.  7]  EDI  is 
the  primary  technology  for  achieving  EC.  EC  also  may  include  electronic  mail  (E-mail), 
electronic  bulletin  boards  (BBS),  electronic  funds  transfer  (EFT),  and  similar  technologies. 
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EC  is  used  to  reduce  paperwork,  communicate  faster,  reduce  errors,  reduce  data  entry 
costs,  strengthen  trading  partner  relationships,  and  lead  to  more  effective  decision  making. 
[Ref  2:  p.  37] 

3.  EC/EDI  in  the  Government/DoD 

In  1993,  the  President  of  the  Unites  States  signed  a  memorandum  directing  the 
Federal  Agencies  to  actively  pursue  streamlining  of  the  procurement  process  through  the 
implementation  of  Electronic  Commerce  (EC),  a  forum  successfully  used  by  large  and 
small  businesses  alike  for  a  number  of  years.  In  the  memorandum,  the  President  noted 
that  moving  to  an  Electronic  Commerce  (EC)  system  to  simplify  and  streamline  the 
acquisition  process  will  promote  customer  service  and  cost-effectiveness.  The  electronic 
exchange  of  acquisition  information  between  private  sector  and  Federal  government 
agencies  (i.e.,  the  use  of  EC)  will  increase  competition.  It  will  do  so  by  improving  access 
to  Federal  contracting  opportunities  for  the  more  than  300,000  suppliers  currently  doing 
business  with  the  Federal  government.  Enhanced  opportunities  would  be,  through  this 
mechanism,  provided  for  small  businesses  and  many  other  suppliers  who  find  access  to 
bidding  opportunities  difficult  under  the  current  system.  To  these  ends,  the  President  set 
forth  the  following  objectives  for  EC: 

•  Exchange  of  acquisition  information  electronically  between  the  private  sector 
and  the  Federal  government  to  the  maximum  extent  practicable. 

•  Provide  businesses,  including  small,  disadvantaged,  and  women- owned 
businesses,  with  greater  access  to  Federal  acquisition  opportunities. 
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•  Ensure  potential  suppliers  are  provided  simplified  access  to  the  Federal 
government's  EC  system.  Employ  nationally  and  internationally  recognized 
data  formats  that  serve  to  broaden  and  ease  the  interchange  of  data. 

•  Use  agency  and  industry  systems  and  networks  to  enable  the  government  and 
suppliers  to  exchange  information  and  access  Federal  acquisition  data. 
[Ref  23:  pp.  45-46] 

The  task  of  developing  the  architecture  and  overseeing  implementation  of  EC  was 
assigned  to  the  Electronic  Commerce  Task  Force  under  the  President's  Management 
Council  (PMC).  In  order  to  complete  the  task  of  the  President's  memorandum,  the  task 
force  chartered  a  Federal  Electronic  Commerce  Acquisition  Team  (ECAT)  and  directed  it 
to  develop  a  comprehensive  plan  for  implementing  an  EC  capability.  [Ref.  23:  p.  46] 
ECAT  recognized  that  the  proliferation  of  implementation  conventions  is  a  major 
stumbling  block  in  the  use  of  EDI  as  the  foundation  of  EC,  and  recommended  the 
development  of  Federal  Implementation  Conventions.  [Ref.  24:  p.  IT- 198] 

4.  Standards  for  EDI  Implementation  Convention 

There  are  two  worldwide  known  standards  for  EDI:  X12  and  United 

Nations/Electronic  Data  Interchnage  For  Administration,  Commerce,  and  Transport 
(UN/EDIFACT).  In  1979,  ANSI  chartered  X12,  Electronic  Data  Interchange,  to  develop 
uniform  standards  for  electronic  interchange  of  business  transactions.  It  was  formed  by 
joining  together  two  industry  standards  groups  that  had  been  developing  EDI  standards 
since  the  late  1960s,  and  that  had  foundation  documents  to  draw  from  immediately. 

The  history  of  EDIFACT  is  relatively  brief.  The  United  Nations  Working  Party  4 
on  Facilitation  of  International  Trade  Procedures  began  its  work  on  international 
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EDIFACT  standards  a  decade  later,  and  did  not  adopt  its  first  message  until  1987.  During 
the  1990's  rush  to  a  global  marketplace,  the  European  Community  92's  lifted  European 
trade  restrictions,  and  the  heavy  use  of  EDI  for  customs  clearance  in  the  Pacific  Rim 
countries  and  New  Zealand  make  international  EDI  standards  a  business  imperative.  This 
has  caused  UN/EDIFACT  to  grow  swiftly.  [Ref.  25:  p.  55] 

In  spite  of  the  late  starting  of  UN/ED1FACT  standards,  worldwide  adoption  of 
these  standards  as  the  basis  for  international  exchange  of  computer-processable  business, 
including  product  data,  is  resulting  in  a  rapidly  multiplying  set  of  competitive  commercial 
networks,  products,  and  services  to  implement  UN/EDIFACT-based  EDI. 

At  the  American  National  Standards  Institute  (ANSI),  Accredited  Standards 
Committee  (ASC),  June  1993  meeting,  the  ASC  X12  organization  formalized  its  intention 
to  migrate  its  standards  to  alignment  with  UN/EDEFACT.  X12  voted  to  adopt 
UN/EDIFACT  as  a  single  standard  after  the  release  of  Version  4  of  the  X12  American 
National  standards,  which  is  expected  in  1997.  The  release  of  Version  4  is  seen  as  the 

logical  beginning  for  migration  of  X 12  to  UN/EDIFACT. 

The  recent  ASC  X12  decision  to  migrate  to  UN/EDIFACT  underscores  the 
emerging  importance  of  these  international  standards.  [Ref.  25:  p.  54] 

5.  EDI  on  the  Internet 

EDI,  by  definition,  includes  the  direct  transmission  of  data  between  firms, 
transmission  using  an  intermediary  such  as  a  value-added  communication  network  (VAN) 
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or  bank,  and  the  exchange  of  computer  tapes,  disks,  or  other  storage  devices  between 
locations.  [Ref.  26] 

There  is  an  easy  way  to  access  and  use  EDI:  the  Internet.  The  Internet  is  the 
inter-connection  and  synergism  of  existing,  connected  corporate  and  government 
networks  utilizing  commonly  used  telecommunications  standards.  [Ref.  22:  p.  6]  The 
Internet  can  be  used  to  do  business  just  like  using  telephone  (and  many  times  it  is  accessed 
through  dial-up  protocols).  The  same  Internet  connection  an  organization  uses  to  send 
electronic  mail  could  also  be  used  to  send  EDI  transactions. 

There  are  benefits  for  EDI  from  Internet: 

•  Adoption  of  common  standards  and  proven  inter-operable  systems. 

•  Adoption  and  deployment  of  a  distributed  Directory  Service  capability,  so  that 
one  can  readily  contact,  electronically,  any  other  organization  in  the  world. 

•  Explicit  commitment  by  participating  organizations  to  cooperatively  route 
traffic,  work  to  resolve  addresses,  and  meet  required  standards. 

•  Layering  of  applications  (such  as  EDI)  over  existing,  proven  applications. 

•  A  standards  process  with  reference  implementations  which  all  vendors  have 
equal  access. 

•  Widely  available  public  domain  software  including,  but  not  limited  to, 
applications,  ptotocol/transports  and  multiple  platform  development  tools. 
[Ref.  21:  pp.  7-8] 

While  EC/EDI  will  certainly  improve  the  internal  communications  and  business 
processes  of  individual  enterprises  with  the  above  mentioned  benefits,  the  real  payback 
comes  when  EC  is  implemented  on  an  inter-enterprise  basis.  It  is  the  inter-enterprise 
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world  in  which  security  needs  become  most  obvious,  beginning  with  authentication  and 
non-repudiation,  and  continuing  into  privacy  through  encryption.  [Ref.  27:  p.  24] 

As  the  methods  for  them,  Ellingen  mentioned  some  of  the  details  in  his  article;  For 
EDI  authentication  and  non-repudiation:  the  digital  signature1  based  on  HyperText 
Transfer  Protocol  (HTTP)2  Security;  and  privacy;  public  key  encryption. 

EC/EDI  are  bringing  major  changes  to  the  world  of  business  domestically  and 
internationally.  It  is  fitting  that  the  largest  international  network,  the  Internet,  should  be 
coming  into  greater  use.  Furthermore,  secure  EDI  over  Internet  is  available  now. 
[Ref.  27:  p.  26] 

F.  CmS  :  MIL-STD-974 

1.  Introduction 

The  Contractor  Integrated  Technical  Information  Service  (CITIS)  is  a  contractor 
-developed  and  maintained  service  providing  electronic  access  and/or  delivery  of 
government-procured  contractually  required  information.  CITIS  is  generally  acquired 
from  prime  contractors  who  may  also  use  electronic  networks  for  access  and  delivery  of 
information  from  their  suppliers.  Thus,  the  prime  contractor  is  the  information  integrator 
for  a  specific  program/product  acquisition.  The  ultimate  goal  of  CITIS  and  CALS,  in 

lA  digital  signature  contains  two  components:  1)  An  undeniable  statement  of  the  identity 
of  the  person  who  signed  the  document;  2)  A  unique  mathematically-computed  number, 
or  "fingerprint"  of  the  document  which  is  signed.  [Ref.  27,  p.  25] 

2A  protocol  used  in  the  World  Wide  Web  (WWW)  technology  which  will  be  the  basis  of 
may  CommerceNet  applications.  [Ref.  27,  p.  24] 
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general,  is  to  reduce  lead  times  and  costs  for  weapons  systems  design,  manufacturing,  and 
support  processes,  and  at  the  same  time  assure  technical  information  accuracy  and 
timeliness.  Figure  3-1  compares  current,  typical  business  practices  with  the  program 
operation  in  the  CITIS  environment.  [Ref.  11:  p.  (7)-3] 


Figure  3-1.  Current  Operating  Environment  vs.  CITIS  Environment  [Ref.  11:  p.  (7)-4] 


2.  Purpose  of  CITIS  Requirements 

This  standard  is  designed  to  be  incorporated  into  a  contract  to  define  the  functional 
requirements  for  a  computer-based  service  to  provide  access  to  information.  CITIS  is 
intended  to  be  an  efficient,  contractually  implementable  means  for  providing  the 
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government  with  on-line  access  to  contractor  generated  data  and  Government  Furnished 
Information  (GFI)  and  the  electronic  transfer  of  such  data.  Ultimately,  CITIS  will  replace 
most,  if  not  all,  contractor  delivery  of  hard  copy  information  currently  required  by  the 
government  throughout  a  programs  life- cycle.  The  requirements  are  specified  in  terms  of 
information  services  and  functions  which  must  be  selected  to  meet  the  needs  of  each  DoD 
acquisition  program.  [Ref  28:  p.  12] 

The  U.S.  government  encourages  industry  to  utilize  a  high  degree  of  information 
integration  across  the  enterprise  and  among  business  partners.  However,  information 
integration  capabilities  are  evolving  within  industry  and,  as  each  CITIS  application  is 
initiated,  it  will  be  necessary  to  establish  baseline  integration  requirements  and  allow  for 
improved  integration  as  the  program  progresses  and  new  technologies  become  available. 
Therefore,  the  process  to  select  specific  functions  and  standards  must  be  coordinated  with 
contractors  and  government  users  throughout  the  program  life  cycle.  [Ref.  28:  p.  12] 

3.  Relationship  of  JCALS  and  CITIS. 

The  government  infrastructure  being  developed  and  the  CITIS  are  viewed  as 
complementary  concepts.  The  JCALS  system  provides  the  preferred  government  gateway 
to  contractor  enterprises.  The  use  of  JCALS  provides  a  known  set  of  interface  parameters 
(i.e.,  data  elements.  Global  Data  Dictionary  and  Directory  (GDD/D),  interface  protocols, 
etc.).  This  will  allow  acquisition  managers  to  easily  construct  "Government  Concept  of 
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Operations"  (GCO)  for  their  programs  that  will  provide  consistent  and  cost-effective 
solutions  over  the  defense  system  life-cycle.  [Ref.  8:  p.  35] 

JCALS  system  specifications  indicate  the  following  four  options  for  bi-directional 
CITIS  interface  (see  Figure  3-2):  1)  non-interactive  data  exchange  using  removable  digital 
media;  2)  selected  CITIS  functions  using  dial-up  or  network  access  capabilities;  3)  on-line 
interface  where  data  dictionaries  are  mapped  to  each  other  for  transparent,  seamless 
access;  and  4)  fully  integrated,  JCALS  site-type  interface  for  which  the  contractor  is 
furnished  GDD/D  services,  software  and,  if  required,  equipment  (dependent  on  the 
infrastructure  already  in  place  at  the  contractor's  site). 

As  the  JCALS  system  evolves,  the  acquisition  manager  should  consider 
implementing  the  fourth  option  of  JCALS/ CITIS  interface  as  the  most  assured 
methodology  of  achieving  compatibility.  However,  if  the  cost-effectiveness  of  this  strategy 
is  prohibitive,  then  providing  the  contractor  with  compatibility  guidance  to  achieve  the 
third  option  of  JCALS/CITIS  interface  is  recommended.  Either  strategy  will  ensure  that 
the  interface  is  streamlined  and  standardized;  minimize  the  problems  incurred  by  an 
acquisition  manager  requiring  access  to  multiple  CITIS  systems;  provide  for  easier 
technical  information  download/transition  to  JCALS;  and  ensure  the  uniformity  of 
software  tools.  Option  3's  interface  is  achievable  through  adherence  to  the  compatibility 
standards  in  Appendix  A  which  are  based  on  the  TRM  and  CALS  standards.  Most 
important  of  these  standards  are  the  data  dictionary  standards.  JCALS  is  in  the  process  of 
submitting  data  elements  for  standardization  through  its  Functional  Data  Administrator 
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(FDA)  and  Defense  Information  Systems  Agency  (DISA).  These  data  elements  will  be 
documented  in  the  JCALS  data  model  and  its  Data  Element  Dictionary.  Options  1  and  2 
represent  the  least  sophisticated  types  of  CITIS  connection,  and  have  several  inherent 
drawbacks  (among  them  are  potential  delays  in  receiving  timely  technical  information). 
Acquisition  managers  should  determine  which  CITIS  options  will  be  implemented  based 
on  a  business  case  analysis  to  be  documented  in  the  GCOs  for  their  programs. 
[Ref.  8:  p.  37] 
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IV.  APPLICATION  FOCUS  AREA 


In  the  JCALS  world  program,  only  the  TM/TO  functionality  has  been  validated  on 
a  joint  service  basis.  The  Army  Strategic  Logistics  Agency  is  now  coordinating  with  the 
Services  to  reach  agreements  on  other  functionalities.  It  appears  that  in  the  near  future 
Logistic  Support  Analysis  and  Engineering  Change  Proposals,  among  others,  will  be 
added  to  the  program.  [Ref.  13]  This  chapter  will  present  some  examples  of  those  areas. 
TM  functionality  is  almost  done  and  DoN  described  it  in  the  Navy/Marine  Corps 
Manager's  Desktop  Guide  for  CALS  Implementation . 

A.  TECHNICAL  MANUAL 

The  first  target  of  the  JCALS  is  the  hard  copy  Technical  Manuals  (TMs)  or 
Technical  Orders  (TOs).  PM  JCALS  is  developing  techniques  through  which  to  digitally 
manage,  acquire  and  improve  these  documents  and  produce  digitally  reproducible  masters. 
From  the  example  of  PHD  NSWC,  Technical  Manual  development  and  publishing  is  the 
only  logistic  functional  element  currently  available  on  JCALS. 

1.  Introduction 

Technical  Manuals  (TM)  are  publications  that  contain  instructions  for  the 
installation,  operation,  maintenance,  and  support  of  defense  systems,  defense  system 
components,  and  support  equipment.  The  digital  environment  for  the  creation, 
management,  and  use  of  TMs  based  on  CALS  standards  is  essentail  for  transitioning  from 
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paper-intensive  defense  system  acquisition  and  support  processes  to  automated  and 
integrated  digital  processes. 

The  Department  of  Defense  (DoD)  CALS  strategy  is  designed  to  promote  the 
digital  creation,  management,  and  use  of  data  in  the  acquisition  and  support  of  DoD 
systems.  CALS  is  not  a  single  system,  but  rather  a  philosophy  that  emphasizes  process 
improvement  and  the  application  of  information  technology  to  those  processes  for  the 
purpose  of  digital  sharing  of  data.  This  includes  the  data  generated  by  the  processes 
required  to  develop  and  maintain  the  TMs.  One  goal  of  CALS  is  to  maximize  the  reuse  of 
data  throughout  the  product  life  cycle.  An  effective  way  to  meet  this  goal  is  to  design  and 
implement  processes  that  are  supported  by  computer  tools.  The  computer  tools  create 
reusable  data  that  can  be  exchanged  electronically  to  optimize  the  process.  The  CALS 
strategy  encourages  well  defined  processes  that  use  computer  tools  for  enterprise 
integration.  Information  architectures  based  on  CALS  strategies  enable  contractors, 
customers,  and  government  agencies  to  share  data,  in  real  time,  to  design,  develop, 
manufacture,  distribute,  and  service  products.  Processes  and  computer  tools,  following 
CALS  strategies  and  information  technologies,  reduce  time-to-market  and  cost,  and 
increase  quality  and  performance.  [Ref.  11,  p  10-5] 

2.  General  Considerations 

The  development  of  a  CALS  strategy  for  TMs  needs  to  be  carefully  examined  to 
maximize  the  value  for  a  specific  defense  system  program  Program  attributes  such  as 
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technology,  costs,  quantities,  and  schedules  have  a  profound  effect  on  the  delivery 
requirements  for  TMs.  The  technical  data  Logistic  Element  Manger  (LEM)  must  consider 
the  life  cycle  of  the  procurement  and  the  infrastructure  in  place  or  being  developed  to 
support  the  TMs  for  their  program. 

TMs  are  any  technical  publication  or  other  form  of  media  used  to  install,  operate, 
maintain  test,  repair,  overhaul,  or  provide  logistic  support  of  ships,  aircraft,  defense 
systems,  or  defense  material.  TM  data  may  be  presented  or  delivered  in  any  media 
including,  but  not  limited  to,  hard  copy,  audio  and  visual  displays,  on-line  access,  magnetic 
tape,  discs,  and  other  electronic  devices.  [Ref.  11,  p  10-10] 

a.  Identify/Establish  the  Requirement  for  the  TM 

The  technical  data  LEM  will  first  identify  the  requirement  to  procure  a  TM 
through  the  development  of  overall  supportability  goals  and  the  initial  maintenance 
philosophy.  This  is  brought  about  through  the  Logistic  Support  Analysis  (LSA)  process. 
The  LSA  process  will  quantify  and  define  requirements  such  as  the  need  to  operate  or 
perform  maintenance  on  equipment.  The  Logistic  Support  Analysis  Record  (LSAR)  will 
contain  the  necessary  task  narratives  for  the  operation  and  maintenance  of  equipment  and 
will  be  used  as  the  primary  source  for  the  development  of  technical  manuals  of  various 
types.  [Ref.  11,  p  10-12] 
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b.  Identifying  the  TM  User's  Requirements 


The  technical  data  LEM  must  now  identify  the  intended  TM  user's 
infrastructure.  The  users  include  those  involved  in  system  acquisition,  review,  and 
approval,  the  TM  management  infrastructure  and  the  end  user.  The  technical  data  LEM 
should  consider  the  existing  and  planned  infrastructures  for  both  government  and 
contractor  facilities;  available  CALS  data  exchange  standards;  and  the  various  digital  data 
deliverable  options  in  terms  of  media,  format,  and  access.  Documentation  of  this 
infrastructure  review  will  take  the  form  of  a  Government  Concept  of  Operations  (GCO), 
and  will  include:  1)  the  hardware  and  software  systems  the  Government  has,  or  is 
developing,  to  manage  and  use  the  data;  2)  data  users,  types  of  data,  frequency  of  use,  and 
timeliness  of  data  access  or  delivery  to  each  user;  3)  data  use  and  the  review  and/or 
approval  processes  to  support  life  cycle  functions;  4)  users'  locations  and  their  primary 
functions  in  support  of  the  defense  system;  5)  data  interchange  requirements  including 
format,  media,  applicable  standards,  and  existing  telecommunications  capabilities;  6) 
access  authorizations  and  restrictions;  7)  data  acceptance  requirements  including  data 
format  and  content  of  data  and  the  government  process  for  accepting  product, 
processable,  or  Contractor  Integrated  Technical  Information  Service  (CITIS)  data;  and  8) 
digital  data  resources  or  source  data  (libraries  of  historical  data,  standards,  and 
specifications)  available  to  support  program  acquisition  and  logistics  processes. 

Acquisition  requirements  for  user  hardware  and  software  to  support  a 
fielded  defense  system  are  normally  under  the  funding  discretion  of  the  technical  data 
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LEM  and  must  be  considered  during  the  CALS  implementation  strategy  and  planning 
process.  [Ref.  11,  p  10-12] 

c.  TMs  in  the  CALS  Environment 

The  technical  data  LEM  should  be  aware  that  it  is  possible  to  acquire  TMs 
in  a  variety  of  forms  depending  upon  the  needs  of  the  users.  Documents  such  as 
maintenance  manuals  may  be  highly  beneficial  when  procured  as  Interactive  Electronic 
TMs  (EETM).  The  IFTM  user  would  be  the  technician  whose  main  concern  is  finding  the 
desired  maintenance-related  information  quickly  and  easily  without  being  burdened  in  the 
field  with  the  entire  maintenance  manual.  Description,  operation,  and  maintenance,  and 
installation  and  checkout  manuals,  however,  may  be  procured  best  in  raster  or  Page 
Description  Language  (PDL)  since  these  manuals  are  not  used  as  often.  Obviously,  it  is 
better  to  leave  these  decisions  up  to  the  individual  program  office  since  each  defense 
system  program  is  unique  in  its  requirements. 

Primary  considerations  for  the  technical  data  LEM  to  address  when 
applying  CALS  to  the  creation,  management,  and  use  of  TMs  is  the  media,  format,  and 
content  of  TM  data  deliverables  and  their  respective  end  users. 

Paper,  microfiche,  and  microfilm  have  been  included  in  this  discussion  of 
CALS  because  much  of  the  TM  inventory  is  still  available  on  these  media.  The  benefits 
associated  with  using  digital  data  far  exceed  the  costs.  For  TMs  some  benefits  of  digital 
data  include:  (1)  improved  handling  and  reduced  storage  of  TM  data  with  electronic  filing 
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and  archiving;  (2)  reduced  costs  associated  with  printing  and  distributing  TMs  by 
providing  on-line  access  to  the  TM  data,  so  that  personnel  could  access  the  data 
repository  from  their  field  activity  and  view  and/or  print  the  specific  TMs  they  require;  and 
(3)  improved  accuracy  and  timeliness  of  the  TM  data,  due  in  part  to  the  simplified 
incorporation  of  change  pages.  [Ref.  11,  p  10-14] 

3.  Life  Cycle  Considerations 

TMs  are  generally  not  required  until  the  later  acquisition  life-cycle  phases  of  a 
defense  system  program.  TMs  available  during  the  earlier  phases  may  he  preliminary 
copies  that  have  not  been  verified  or  have  not  received  final  acceptance  but  are  useful  for 
test  verification,  training,  and  operation.  Final  Reproducible  Copies  (FRC)  are  available  in 
the  later  phases.  The  technical  data  LEM  must  consider  the  information  volume  and 
typical  use  of  the  data  generated  during  each  of  these  phases  to  determine  the  appropriate 
TM  deliverable  format.  Note  that  the  deliverable  format  may  be  different  for  each  phase 
(e.g.,  preliminary  versions  delivered  in  mutually- agreeable  word-processing  format  and 
FRC  s  in  SGML  format).  [Ref.  11,  p  10-16] 

4.  Contract  Data  Requirements  Lists  (CDRLs) 

Delivery  of  defense  system  data  in  digital  form  requires  changes  to  the  solicitations 
and  contracts  including  their  attachments  and  enclosures.  These  changes  should  be  made 
with  full  consideration  of  the  ability  of  defense  activities  to  make  cost  effective  use  of 
digital  data  deliverables  or  access.  Each  defense  system  program  may  include  unique 
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requirements  for  which  additional  program- specific  tailoring  will  he  needed.  Most  of  the 
applicable  CALS  standards  and  specifications  contain  contract-negotiable  options  from 
which  the  technical  data  LEM  must  choose  to  satisfy  program- specific  requirements 
including  multiple  classes  or  types  of  data  formats. 

The  TM  Contract  Requirements  (TMCR)  will  identify  the  types  of  TMs  required 
and  include  language  that  specifies  exactly  how  data  will  be  delivered  (including  media, 
format,  and  content)  under  the  contract.  CALS  standards  should  be  invoked  whenever 
possible  for  digital  delivery  of  support  products  such  as  engineering  drawings  and  TMs. 
The  media  for  delivery  such  as  magnetic  tape,  optical  disk,  or  on-line  (networks,  telephone 
modems,  CITIS)  should  be  compatible  with  Government  receiving  system  capabilities. 
Some  digital  deliverables,  especially  interim  deliverables,  may  be  efficiently  acquired  by 
agreeing  on  a  common  word  processing  package  in  the  contract  and  specifying  the 
appropriate  and  compatible  physical  media  such  as  magnetic  disk,  magnetic  tape,  etc. 
[Ref.  ll,p  10-16] 

5.  Interactive  Electronic  TM  (IETM) 

An  IETM  is  a  computer-based  collection  of  information  needed  for  the  diagnosis 
and  maintenance  of  a  defense  system  It  is  optically  arranged  and  formatted  for  interactive 
presentation  to  the  end  user  on  an  electronic  display  system  Unlike  other  optical  systems 
that  display  a  page  of  text  from  a  single  document,  IETMs  present  interrelated  information 

from  multiple  sources  tailored  to  user  queries. 

Specifications  for  defining  IETMs  include: 
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•  MIL-D-87269,  Database,  Revisable:  Interactive  Electronic  Technical 

Manuals,  for  the  Support  of 

•  MIL-M-87268,  Manuals,  Interactive  Electronic  Technical:  General  Content, 
Style,  Format,  and  User- Interaction  Requirements 

•  MEL-Q-87270,  Quality  Assurance  Program:  Interactive  Electronic  Technical 
Manuals  and  Associated  Technical  Information;  Requirements  for 

An  IETM  is  essentially  a  hypertext  document,  which  consists  of  a  collection  of 
"interconnected  writings."  These  interconnections  allow  a  user  to  browse  through  a 
document  by  selecting  points  of  interest  or  hot  spots  that  may  be  connected  to  other 
related  text,  hot  spots,  or  menus.  The  user  could  then  continue  to  follow  along  these 
"paths"  to  other  cross-referenced  points  in  that  collection  of  writings.  This  creates  a 
"pageless"  document  that,  depending  on  the  source  database,  can  contain  a  collection  of 
information  from  a  variety  of  sources.  Also,  rather  than  limiting  these  documents  to  pure 
text,  we  may  incorporate  graphics,  audio,  video,  and/or  computer  programs  into  the 
content  of  the  document,  creating  what  is  known  as  a  hypermedia  document. 

By  streamlining  access  to  the  desired  information  and  by  providing  multiple  paths 
to  other  related  information,  the  IETM  offers  a  more  efficient  and  more  comprehensive 
method  of  using  technical  information.  Unrestricted  by  the  page- oriented  display  and  the 
use  of  sole- source  information,  the  IETM  duplicates  on  the  Personal  Computer  (PC),  the 
research  environment  available  in  a  well- equipped  multimedia  library;  displays  only  the 
actions  appropriate  for  resolving  a  specific  problem;  provides  fault-isolation  tables  and 
diagrams;  and  guides  the  technician  through  the  troubleshooting  process  via  a 
user-friendly  query  method.  IETMs  permit  the  user  to  locate  information  more  easily  and 
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to  present  it  faster  and  more  comprehensively  in  a  form  that  requires  much  less  storage 
than  paper.  [Ref.  11,  p  10-22] 

a.  IETM  Viability 

The  technical  data  LEM  should  consider  whether  the  TM  will  ultimately  be 
used  in  an  interactive  computer  environment,  the  IETM.  The  IETM  format  offers  the  user 
distinct  advantages  over  the  traditional  TM.  Some  IETM  benefits  include:  1)  reduction  in 
the  false  removal  rate  of  Line  Replaceable  Units  (LRU)  or  Weapon  Replaceable 
Assemblies  (WRA);  2)  reduction  in  troubleshooting  time;  3)  reduction  in  the  TM  support 
costs  associated  with  distribution,  management,  and  storage;  and  4)  allowing  training 
activities  to  concentrate  more  on  generalized  training  versus  system  specific  training.  The 
technical  data  LEM  should  first  determine  whether  the  end  item  or  defense  system 
program  is  currently  in  the  early  phases  of  design,  whether  the  life  cycle  requirements  for 
the  TM  exceed  five  years,  and  whether  the  Technical  Data  Package  (TDP)  or  LSAR 
database  contains,  or  can  be  economically  altered  to  include,  a  numbering  system  similar 
to  MIL-STD-1808.  If  any  of  these  considerations  can  be  answered  "NO,"  then  an  IETM  is 
not  recommended.  If  all  considerations  can  be  answered  "YES,"  then  a  business  case 
analysis  should  be  performed  to  determine  the  economic  feasibility  of  the  IETM.  If  results 
from  this  analysis  recommend  pursuing  an  IETM  or  quality  readiness  and/or  support 
factors  lend  adequate  credence  to  the  need  for  an  IETM,  development  of  an  IETM  should 
be  pursued.  In  this  case,  develop  IETM.  [Ref.  11,  p  10-23] 


81 


b.  IETM  Development 


Once  IETM  development  has  been  decided,  the  technical  data  LEM  must 
first  determine  whether  this  effort  will  be  associated  with  an  existing  IETM  in  terms  of 
either  the  modification  of  an  existing  IETM  or  the  creation  of  a  supplement  to  an  existing 
IETM.  If  this  is  indeed  the  case,  then  the  technical  data  LEM  must  determine  whether  an 
existing  infrastructure  and  display  device  will  be  used  in  conjunction  with  the  IETM  and 
whether  this  infrastructure  uses  a  proprietary  format.  If  all  of  the  above  conditions  are 
true,  then  the  final  IETM  developed  should  remain  in  the  existing  proprietary  format. 
However,  if  any  of  these  conditions  is  not  met,  then  it  is  advised  that  the  IETM  be 
developed  using  the  new  IETM  standards.  [Ref.  11,  p  10-24] 

B.  LOGISTICS  SUPPORT  ANALYSIS  (LSA) 

This  section  presents  about  LSA.  LSA  has  not  been  validated  by  all  joint  services 
yet.  But  it  has  been  tested  in  prototype  sites.  The  Army  Strategic  Logistics  Agency  is 
coordinating  with  the  Services  to  reach  agreement  on  this  functionality.  Followings  are 
from  the  Guide  of  DoN. 

1.  Introduction 

Logistics  Support  Analysis  (LSA)  is  a  systematic  and  comprehensive  analytical 
process  that  is  conducted  on  an  iterative  basis  through  all  life  cycle  phases  of  the 
system/equipment.  LSA  is  for  quantifying  and  measuring  supportability  objectives 
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(supportability  includes  all  elements  of  Integrated  Logistics  Support  (ILS)  required  to 
operate  and  maintain  the  system/equipment.)  Depending  on  the  level  of  tailoring, 
extensive  amounts  of  information  and  data  are  required  as  an  input  to,  and  generated  as  a 
result  of;  the  LSA  process.  The  LSA  process  fits  into  the  ILS  process  as  LSA  tasks  are 
planned,  initial  front  end  analyses  are  performed,  and  LSA  information  is  generated. 

LSA  information  consists  of  all  data  resulting  from  the  analysis  tasks  conducted  as 
defined  in  MIL-STD- 1388-1 A  and  is  intended  to  be  the  primary  source  of  validated, 
integrated,  design-related  product  support  information  pertaining  to  an  acquisition 
program  LSA  information  is  developed  and  maintained  as  a  result  of  design,  support,  and 
operational  concept  development  and  is  updated  to  reflect  changes. 

LSA  Record  (LSAR)  data  is  a  subset  of  LSA  information  and  is  a  structured 
means  of  aggregating  LSA  data.  It  is  available  for  use  by  all  services  and  ILS  element 
functional  areas.  Because  each  element  of  LSAR  data  is  defined  and  has  a  specified  data 
structure,  the  LSAR  has  evolved  as  the  primary  means  of  storing  logistic  support  data  in 
digital  media.  [Ref.  11,  p  11-5] 

2.  CALS  and  LSA  by  Functional  Activity 

Considerations  that  must  be  addressed  when  an  Acquisition  Manager  is  acquiring 
LSA  data  in  digital  format  include:  1)  specifically  who  will  use  the  data?;  2)  what 
hardware  and  software  are  needed  to  use  it?;  3)  will  the  digital  data  be  applied  directly  or 
as  source  information  for  the  follow-on  products?;  and  4)  are  there  digital  data  sources 
available  that  can  be  used  as  input  to  the  LSA  process  if  source  data  is  available,  who  has 


83 


it,  what  form  is  it  in,  and  are  there  any  challenges  associated  with  providing  it?  These 
considerations,  to  various  degrees,  must  be  addressed  by  the  Acquisition  Manager  for  and 
within  each  of  the  three  major  activities  (create,  manage,  and  use)  associated  with  LSA 
data  acquisition.  [Ref  11,  p  11-7] 

3.  Current  Considerations  for  the  LSA  Process  in  a  CALS  Environment 

The  four  prime  factors  that  govern  system  acquisition  programs  are  cost,  schedule, 
performance,  and  supportability.  The  LSA  process  provides  direct  input  into  the 
supportability  and  cost  factors  associated  with  a  system/equipment  and,  therefore, 
provides  significant  input  into  system/equipment  decisions.  The  CALS  environment  offers 
the  opportunity  through  digital  application  of  the  LSA  process  for  reductions  in  Life  Cycle 
Cost  (LCC).  The  ability  to  create  data  once  (including  LSA,  engineering,  and  ILS  data) 
and  use  it  many  times  impacts  the  cost  of  the  LSA  process  and  the  follow-on  support 
costs.  If  the  LSA  data  and  associated  analyses  (FMECA,  RCM,  etc.)  are  created  in  a 
digital  format,  then  digital  data  required  for  the  LSA  can  be  linked  and  fed  to  the  LSAR 
database  in  an  automated  fashion.  The  initially  created  LSA  data  is  then  available  for  use 
in  all  technical  data  products.  The  Acquisition  Manager  must  consider  the  digital  format, 
media,  HW/SW  issues,  required  framework,  architecture,  and  Government  infrastructure 
when  developing  the  Government  Concept  of  Operations  (GCO)  concurrently  with 
selecting  LSA  tasks.  [Ref.  15,  p  11-16] 


84 


4.  Future  Considerations  for  the  LSA  Process  in  a  CALS  Environment 


This  paragraph  will  present  some  thoughts  on  where  CALS  is  headed  and  how  that 
might  affect  data  use  in  the  future.  The  influence  of  infrastructure  developments  in  the 
Navy,  within  the  DoD,  and  even  in  the  international  community  will  all  affect  the  potential 
environment  in  which  the  LSA  data  acquired  now  may  have  to  be  used  in  the  future.  [Ref. 
11,  p  11-25] 

a.  Integrated  Weapon  Systems  Database  (IWSDB) 

Future  trends  must  lead  to  and  support  the  fundamental  objective  of  CALS, 
which  is  to  lower  costs  to  the  Government,  improve  quality,  and  shorten  lead  times.  The 
electronic  sharing  of  data  allows  it  to  be  created  once  and  then  used  by  multiple  users, 
multiple  times.  The  integration  of  functional  processes  will  start  with  the  integration  of 
data.  The  acquisition  strategy  must  specifically  address  the  automation  and  integration  of 
technical  information  systems  and  functional  processes. 

The  process  for  determining  LSA  data  and  LSAR  database  requirements  is 
an  extension  of  the  process  currently  used  for  determining  data  requirements,  selecting 
appropriate  data  items,  and  developing  the  Contract  Data  Requirements  List  (CDRL)  that 
identifies  the  requirements.  The  LSA/LSAR  databases  are  the  building  blocks  that  are 
necessary  to  support  an  IWSDB.  The  process  for  determining  LSA  data  and  LSAR 
database  requirements  may  evolve  as  the  requirement  for  access  to  the  data  intensifies. 
There  is  significant  potential  for  reduction  of  data  requirements  in  that,  with  query 
capability,  the  Government  can  generate  data,  reports,  and  products  on  demand  rather 
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than  having  the  contractor  prepare  and  deliver  them.  As  digital  data  utilization  evolves,  the 
media  on  which  the  data  is  delivered  will  also  evolve  as  depicted  on  Figure  11-9. 
[Ref.  11:  p  11-24] 

b.  Contractor  Integrated  Technical  Information  Service  (CITIS) 

Access  to  digital  data  will  become  the  standard  by  which  all  acquisitions 
will  be  measured.  Because  CITIS  provides  access  to  contractor-managed, 
functionally-integrated  information,  it  must  play  a  significant  role  in  improved  Government 
operations  and  the  streamlining  of  processes.  An  effective  CITIS  program  will  require 
foresight  and  added  coordination  efforts  on  the  part  of  contractors.  Government  sponsors, 
and  potential  CITIS  users.  Functional  integration  approaches,  as  well  as  CITIS 
performance,  must  be  considered.  Measures  should  be  developed  to  motivate  contractors 
with  top-level  commitments  to  produce  overall,  functional  integration  and  an  effective 
CITIS  implementation. 

An  effective  LSA  program  will  be  planned,  integrated,  developed,  and 
conducted  in  conjunction  with  the  requirements  of  the  overall  acquisition  program 
objectives.  The  LSA  process  will  be  established  consistent  with  the  type  and  phase  of  the 
acquisition  program  To  maximize  the  use  of  the  plans,  procedures,  front-end  analyses  and 
reports  developed  from  selected  LSA  tasks,  it  is  necessary  to  establish  a  viable 
communication  link  with  the  contractor.  Providing  an  early-on  CITIS  capability  (including 
analyses  and  documentation  generated  from  the  200  &  300  series  tasks  of 
MEL- STD- 13 88-  1A)  will  enhance  the  LSA  process  and  the  overall  design  effort. 
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There  are  several  considerations  facing  contractors  when  they  are  tasked 
with  providing  CITIS  to  support  LSA  databases.  Areas  of  consideration  include  the 
following. 

•  Type  of  DBMS  or  languages:  The  number  and  disparity  among 
database  management  systems,  programming  languages,  data  models, 
data  descriptions  or  data  organizations,  and  interface  and  access 
languages; 

•  Data  element  format:  The  number  of  discrete  techniques  for  re 
formatting  data  to  be  presented  to  the  user  in  a  predefined,  standard 
format  including  conversion  of  units  of  measure,  translation  into 
standard  format,  and  other  agreed  upon  translations  or  conversions; 

•  Source  or  location  of  data  and  applications:  The  user  must  know  the 
differences  concerning  location,  hardware,  operation  system, 
programming  language,  and  access  methods  for  specific  systems; 

•  Relationship  and  dependencies:  The  degree  to  which  the  user  must 
keep  track  of  data  relationships  and  dependencies  within  and  across 
integrated  data  sets; 

•  Version  knowledge  and  control:  The  degree  to  which  the  user  must 
ensure  that  data  retrieved  from  more  than  one  system  and  database  are 
consistent  in  terms  of  data  values,  version  or  status,  and  context. 
[Ref.  11:  p.  11-25] 


C.  ENGINEERING  DATA  MANAGEMENT  SYSTEMS 

This  section  includes  two  real  life  examples  of  improvements  and  benefits 
introduced  by  implementation  of  CALS  in  both  industry  and  government  engineering 
document  management  systems.  [Ref.  29:  p.  10] 


87 


1.  ECARDS 


General  Dynamics  (GD),  Land  Systems  Division  located  in  Warren,  Michigan  has 
over  the  past  four  years  implemented  the  Engineering  Computer  Aided  Retrieval  and 
Distribution  System  (ECARDS)  that  is  an  information  management  system  for  raster 
image  data.  General  Dynamics  builds  tanks  for  the  U.S.  Army  and  foreign  governments. 
With  the  implementation  of  ECARDS,  GD  has  taken  the  first  step  in  moving  toward  a 
paperless  production  of  a  defense  product:  the  M1A1  Tank.  The  current  paper  based 
M1A1  repository  is  being  scanned  into  the  system  from  both  paper  and  aperture  card 
originals.  Images  are  being  stored  digitally  onto  optical  disk.  The  system  is  completely 
computer  controlled,  automatic,  and  has  the  capability  of  providing  audit  logs  for  the 
tracking  of  image  file  retrieval  and  printing.  The  system  also  has  access  security  built  into 
the  user  interface  application.  ECARDS  utilizes  the  MIL-R-28002,  Type  II  CALS 
standard  for  all  image  files.  This  raster  data  format  known  as  TRJOF  (Tiled  Raster 
Interchange  Format)  is  tiled  on  512  pixel  boundaries  and  compressed  via  the  CCITT 
Group  IV  compression  standard.  Currently  the  ECARDS  system  is  limited  to  storing  and 
retrieving  only  raster  image  data.  The  next  step  in  the  evolution  of  ECARDS  is  to 
incorporate  both  CAD,  vector  files  and  technical  publishing  files.  These  formats  will  be 
implemented  using  the  IGES  and  SGML  standards  respectively. 

Also  recently  implemented  within  ECARDS  is  the  ability  to  transfer  image  data  to 
and  from  the  government.  The  U.S.  Army  Tank  Automation  Command  (TACOM)  is  the 
General  Dynamics'  largest  customer.  TACOM  has  implemented  a  system  called  DSREDS 
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for  (Digital  Storage  and  Retrieval  Engineering  Documentation  System).  It  is  now  possible 
for  a  user  of  the  ECARDS  system  to  send  image  data,  drawings,  and  documents  to  the 
DSREDS  system  electronically.  Also,  a  user  of  the  DSREDS  system  can  automatically 
access  the  ECARDS  database  to  search  for  and  retrieve  image  files  electronically. 
TACOM  users  can  accomplish  this  by  remotely  accessing  a  3270  terminal  emulation 
session  with  the  IBM  mainframe  computer  at  General  Dynamics  and  interacting  with  the 
configuration  management  application.  The  second  step  is  the  ordering  of  the  desired 
image  file  or  series  of  files,  upon  system  approval,  through  an  X-windows  user  interface 
session  that  interacts  with  the  ECARDS  storage  and  retrieval  application.  The 
communication  media  between  systems  can  be  a  T1  leased  line  or  an  internet  network. 
This  capability  —  government  access  of  contractor  database  —  is  an  example  of  CALS 
phase  n  Contractor  Integrated  Technical  information  Services  (CITIS)  implementation. 
This  is  just  the  first  step  in  fully  implementing  a  complete  paperless  data  interchange 
environment.  This  project  shows  how  progress  is  being  made  to  accomplish  the  goals  of 
CALS  objectives  in  a  step  by  step  fashion.  [Ref.  29:  p.  10] 

2.  HSTTMIS 

The  Technical  Management  Information  System  (TMIS)  at  the  NASA,  Goddard 
Space  Flight  Center  in  Greenbelt,  Maryland  is  in  the  process  of  being  upgraded  to  support 
CALS  standards.  At  Goddard,  TMIS  is  used  as  a  complete  engineering  data  management 
system  for  the  Hubble  Space  Telescope  (HST)  project.  TMIS  is  being  used  as  a  repository 
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for  all  relevant  engineering  data  and  technical  documentation  related  to  the  design, 
maintenance,  and  support  of  the  HST.  The  HST  TMIS  operation  is  a  real  life  example  of 
what  problems  occur  when  an  engineering  document  management  system  is  implemented 
according  to  CALS  specifications. 

In  the  past,  TMIS  consisted  of  many  different  databases  (one  for  drawings,  one  for 
documents,  and  others  for  engineering  changes,  parts  lists,  etc.).  In  order  to  successfully 
implement  a  system  that  is  capable  of  electronically  storing  and  controlling  HST  data 
many  things  must  be  done  up  front.  First,  the  data  must  have  a  high  degree  of  integrity; 
the  drawing  and  document  database  indexes  must  match  the  data.  Second,  there  must  be 
a  means  of  accessing  all  relevant  databases  from  one  system  Third,  vendors  who  supply 
documentation  in  support  of  their  products  must  be  willing  to  supply  information  via 
standard  electronic  means.  Fourth,  data  must  be  converted  to  digital  form  before  a  full 
system  can  be  implemented  and  used. 

In  the  recent  past  vendors  would  take  product  data,  engineering  drawings,  support 
documentation,  training  material,  repair  material,  etc.,  (most  of  which  was  generated  in 
electronic  form),  and  send  it  to  the  HST  TMIS  operation  in  paper  form  At  that  point 
TMIS  operators  would  be  required  to  digitize  this  information,  index  it,  and  store  it  in 
digital  form  within  the  TMIS  system  This  involves  (1)  going  from  a  digital  form  (CAD 
and  Word  processor  generated  data)  to  (2)  a  paper  form,  and  back  to  (3)  a  digital  form  for 
input  into  the  system.  The  costs  of  this  redundant  and  unnecessary  re-digitizing  of 
documentation  is  what  CALS  is  trying  to  minimize.  TMIS  managers  are  in  the  process  of 
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eliminating  this  problem  by  adopting  the  capability  of  accepting  data  electronically  from  all 
vendors.  This  capability  alone  will  save  substantial  costs  associated  with  the  printing  of 
images,  the  transportation  of  printed  material,  the  indexing  of  the  material,  and  the 
scanning  and  digitizing  of  the  material,  not  to  mention  the  costs  of  the  equipment 
necessary  to  do  this  work. 

The  goal  of  HST  TMIS  managers  is  to  get  to  a  point  where  all  information 
associated  with  the  HST  products  can  be  transferred  and  accepted  electronically  through 
the  use  of  CALS  standards.  The  TMIS  system  uses  the  MIL-R-28002,  Type  II  (TRIF) 
data  standard  for  raster  image  data.  TMIS  has  the  ability  to  convert  TRIF  data  files  to  and 
from  other  industry  standard  formats  and  some  that  are  proprietary  in  nature.  The  HST 
TMIS  system  is  being  upgraded  with  application  software  that  allows  for  a  complete 
CALS  compliant  solution  by  incorporation  of  off-the-shelf  software  application  programs 
into  the  system.  TMIS  can  store,  retrieve,  and  control  any  type  of  file  (raster,  CAD,  tech 
pubs,  CGM  illustrations,  etc.). 

HST,  TMIS  managers  have  found  that  supporting  CALS  standards  within  your 
organization  or  system  is  only  half  of  the  problem.  Many  problems  have  been  identified  in 
the  process  of  implementing  this  capability.  Requiring  the  various  vendors  who  supply 
product  data  (sometimes  hundreds  of  companies)  to  supply  data  in  one  common  format 
(CALS  compliant  or  not)  has  proven  to  be  a  very  difficult  thing  to  do.  For  example,  of  the 
main  HST  suppliers  of  information,  which  consists  of  approximately  seven  companies 
Lockheed  Missiles  and  Space  Company,  Ball  Aerospace,  Electro  Optics  Cryogenics 
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Division,  Hughes  Danbury  Optical  Systems,  the  University  of  Arizona,  and  the  European 
Space  Agency,  has  a  different  type  of  CAD  system  that  is  used  to  generate  engineering 
data.  It  has  was  discovered  by  HST,  TMIS  managers,  through  a  painful  process,  that  the 
Initial  Graphics  Exchange  Specification  (IGES)  standard  is  not  supported  in  the  same 
manner  by  each  CAD  system  and  software  vendor.  This  means  that  IGES  files  written  by  a 
particular  application  may  not  be  readable  in  its  entirety  by  a  second  vendor  MES 
program.  In  most  cases,  character  and  notation  data  is  what  drops  out  upon  electronic 
data  interchange  between  systems.  This  data  is  only  recovered  by  manual  means  via  labor 
intensive  quality  control;  this  is  a  costly  proposition.  This  problem  can  only  be  solved  with 
time,  better  definition  of  the  standard,  and  incentive  on  the  CAD  manufacturers  to 
implement  and/or  upgrade  field  software  with  CALS  compliant  versions.  It  will  become 
increas-ingly  more  important  to  each  of  these  vendors  as  more  and  more  government 
contracts  require  CALS  compliancy  in  the  future.  [Ref.  29:  p.  1 1-12] 
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V.  RECOMMENDATIONS  FOR  THE  ROK  ARMY 


A.  LESSONS  FROM  U.S.  CALS 

CALS  started  as  a  program  that  managed  several  Information  Technologies  (ITs) 
to  achieve  greater  efficiency  in  the  acquisition  and  logistics  businesses.  Effectively 
managing  IT  inherently  implies  managing  change.  The  ongoing  technological  revolution 
within  this  field  shows  no  sign  of  abating.  IT  mangers  are  subject  to  the  same  forces  that 
are  forcing  change  in  other  area,  and  are  themselves  responsible  for  one  of  these  driving 
factors  of  change  within  business  and  society.  Therefore,  much  of  the  writing  on 
implementing  IT  focuses  on  change.  Furthermore,  IT  projects  like  CALS  permeate  every 
functional  area  of  the  organization,  so  their  changes  inevitably  require  organization-wide 
adaptation. 

One  of  a  manager's  critical  concerns  is  IT  integration.  Integrating  IT  covers  two 
topics.  The  first  is  designing  the  system  so  that  it  is  supportive  of  the  enterprise  wide 
goals.  The  second  is  the  actual  implementation  of  new  systems.  Both  can  be  accomplished 
through  a  common  approach.  Carol  Beatty  has  identified  the  factors  involved  in  doing  this 
successfully.  She  identifies  three  factors : 

•  An  effective  champion.  Usually  someone  with  some  backing  from  senior 
management,  this  person  must  especially  have  the  political  skills  to  negotiate 
among  the  various  coalitions  that  exist  across  functional  lines. 

•  A  plan  for  system  integration.  As  self  evident  as  this  may  seem,  only  about  half 
of  the  firms  implementing  new  IT  systems  have  any  plan  at  all  for  tying 
together  the  systems  of  their  firm  Indications  are  that  the  most  successful 
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method  to  date  for  formulating  and  implementing  these  plans  are  through 
cross-jurisdictional  committees  and  teams. 

•  Steering  committees  and  implementation  teams.  Because  of  the  complexity  and 
interrelatedness  inherent  in  an  information  system  that  spans  all  aspects  of  an 
organization,  it  is  unlikely  that  any  one  person  would  have  all  the  expertise  and 
insight  to  design  an  optimum  system  Even  if  they  did,  they  would  than  face  a 
daunting  task  educating  and  gaining  the  support  of  the  many  diverse  coalitions 
that  exist  in  any  large  organization.  Steering  committees  exist  at  the  senior 
management  level  with  a  medium  to  long  range  time  frame.  They  are  primarily 
responsible  for  integrating  the  IT  effort  it  the  organizations  overall  strategy. 
The  implementation  teams  represent  the  users  of  the  system,  they  are  involved 
in  the  nuts  and  bolts  of  the  actual  system  development.  [Ref.  30] 

Based  on  this  theoretical  framework,  I  would  like  find  some  lessons  from  the  U.  S. 
CALS  effort. 

1.  An  Effective  Champion 

CALS  has  received  support  from  senior  leadership,  both  the  President  and  the 
Secretary  of  Defense.  Since  September  1985,  when  CALS  was  initiated  by  a  memorandum 
of  the  Deputy  Secretary  Defense,  Taft,  there  were  several  efforts  to  embed  the  purposes 
of  CALS  in  the  DoD.  At  the  beginning,  the  formalizing  of  the  acquisition  process  by  DoD 
Instruction  5000.2  helped  to  institutionalize  infrastructure  modernization  by  JCALS  and 
Joint  EDMICS  programs  and  CITIS  development.  [Ref.  31:  p.  48]  Recently  in  October 
1993,  President  Clinton's  memorandum  made  the  use  EDI  mandatory  in  new  procurement 
systems  being  developed  across  all  federal  agencies. 

A  change  champion  was  formally  organized  as  PM  JCALS  which  was  definitely  a 
benefit.  Unfortunately,  the  actions  of  some  of  their  personnel  endangered  the  program, 
highlighting  the  need  for  high  quality,  well  trained  people  to  manage  it. 
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2.  A  Plan  for  System  Integration 


As  is  the  case  with  many  large  IT  projects,  the  lack  of  clearly  defined  requirements 
proved  to  be  problematic.  In  its  report,  the  Government  Accounting  Office  (GAO) 
criticized  JCALS  implementation.  "There  is  great  uncertainty  as  to  whether  JCALS  will 
meet  user  needs,"  GAO  said.  The  services,  the  report  noted,  have  not  reached  a 
consensus  on  format  and  data  content  requirements  for  the  technical  manuals.  According 
to  report,  Dr.  Tomlinson,  PM  JCALS  program  manager,  said  it  probably  would  take  two 
or  five  years  to  come  to  such  an  agreement.  [Ref.  32] 

The  Pentagon  CALS  office  said  "We  understand  the  need  to  clearly  define  the 
CALS  initiative  and  what  it  encompasses.  We  have  defined  the  initiative  very  clearly  in  the 
CALS  Phase  II  Architecture  Deployment  Plan,  which  is  expected  to  be  circulated  by  the 
beginning  of  the  calendar  year."  [Ref.  32] 

Another  common  problem  in  IT  projects  is  that  of  requirements  creep.  Since 
CALS's  inception  in  1985,  it  has  undergone  several  transformations.  DoD  intended  to 
computerize  the  technical  and  logistics  data  for  weapon  system  development.  In  its 
current  form,  CALS  encompasses  the  entire  life  cycle  of  weapon  systems. 

GAO  said,  "Although  DoD  has  expanded  the  CALS  scope,  the  department  has 
failed  to  define  the  initiative  and  its  implementation.  Despite  the  significant  potential 
benefits  offered  by  CALS,  there  is  no  single  point  of  accountability  for  the  initiative. 
Instead,  management  responsibilities  are  diffused  throughout  government  and  industry." 
[Ref.  32] 
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One  very  positive  lesson  learned  from  the  U.S.  experience  is  the  importance  of  an 
evolutionary  approach  to  the  acquisition  through  the  use  of  prototypes  for 
implementation.  As  aforementioned  earlier,  DoD  estimated  a  need  for  over  250  JCALS 
sites  over  the  world.  DoD  has  tested  6  prototyping  sites  and  Dr.  Tomlinson  said  this  : 
"The  Joint  Computer-aided  Acquisition  and  Logistics  Support  (JCALS)  program  has 
successfully  employed  prototyping  as  part  of  its  evolutionary  acquisition  strategy.  The 
incorporation  of  prototyping  into  the  JCALS  acquisition  strategy  is  not  only  a  sound 
design/development  methodology  but  is  consistent  with  the  DoD  guidance  in 
DoDI  8120.2.  Guidelines  in  this  policy  instruction  show  that  prototyping  may  be  used 
throughout  the  life  cycle  management  process.  The  prototyping  concepts  provide  an 
opportunity  to  significantly  reduce  risks  to  the  JCALS  program  and  to  provide  better 
responsiveness  to  the  users  of  the  JCALS  system."  [Ref.  33] 

3.  Steering  Committees  and  Implementation  Teams 

Good  use  has  been  made  of  steering  committees  at  DoD  and  DISA,  and 
implementation  teams  in  NIST  and  industry.  Within  DoD,  the  CALS  &  EDI  Office  of  the 
Under  Secretary  of  Defense  (Acquisition  and  Technology)  is  responsible  for  issuing  CALS 
directives  and  coordinating  CALS  efforts  among  DoD  military  departments  and  agencies. 

The  Defense  Information  Systems  Agency  (DISA)  is  responsible  for  maintaining 
DoD  information  technology  standards  and  conventions.  Within  DISA,  the  Center  for 
Standards,  part  of  the  Joint  Interoperability  and  Engineering  Organization,  is  the 
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designated  configuration  manager  for  DoD  Electronic  Commerce/Electronic  Data 
Interchange  (EC/EDI)  standards.  [Ref.  34] 

The  National  Institute  of  Standards  and  Technology  (NIST),  a  part  of  the 
Department  of  Commerce,  has  been  tasked  to  provide  the  DoD  assistance  in  developing 
the  CALS  standards.  NIST  works  with  military  departments  and  agencies,  industry  and 
national  and  international  standards  organizations  to  develop  the  CALS  initiative 
standards  and  make  recommendations  to  the  CALS  and  EDI  Office  on  which  standards  to 
implement. 

The  CALS  initiative  being,  a  joint  DoD-industry  program,  is  primarily  represented 
by  the  CALS  Industry  Steering  Group  (ISG).  The  CALS  ISG  leadership  has  recently 
renamed  the  CALS  initiative  to  Commerce  at  Light  Speed  to  better  reflect  the  ISG's 
opinion  that  CALS  strengths  rest  with  Enterprise  Integration  (El)  efforts  in 
manufacturing. 

The  CALS  ISG  has  formed  Regional  Interest  Groups  (RIGs)  to  meet  periodically 
with  industry  representatives  to  keep  them  current  with  the  latest  CALS  developments. 
At  the  time  of  this  writing  there  are  CALS  RIGs  in  at  least  25  states.  [Ref.  7:  pp.  1 1-13] 

At  the  seventh  annual  CALS  conference  and  exposition  on  December  6,  1994,  the 
CALS  ISG  Executive  Advisory  Council  announced  the  formation  of  CALS  International. 
CALS  International  will  serve  to  advance  international  business  by  promoting  the  use  of 
standards  and  shared  digital  data  in  electronic  commerce.  Presently,  there  are  nine  nations 
with  CALS  ISG  organizations:  United  States,  Canada,  United  Kingdom,  France, 
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Germany,  Sweden,  Japan,  Taiwan,  and  Australia.  Additional  countries  are  expected  to 
formalize  a  CALS  organization  with  the  announcement  of  CALS  International. 

The  CALS  International  will  consist  of  three  elements:  1)  International  Board  of 
Directors  (like  a  steering  committee),  responsible  for  setting  priorities,  defining  long-range 
objectives  and  forging  strategic  partnerships  and  cooperative  relationships;  2)  the 
International  CALS  Congress  (like  an  implementation  team),  responsible  for  developing  a 
coordinated  approach  to  implementing  CALS  requirements;  and  3)  the  International 
CALS  Secretariat,  responsible  for  providing  staff  support. 

4.  CALS  Culture  Shock 

Schein  identifies  the  introduction  of  new  technology  as  a  cultural  change  problem. 
Benjamin  and  Blount  further  indicate  that  organizations  have  often  not  reaped  the 
promised  benefits  because  they  have  not  understood  the  need  to  develop  new  processes 
when  developing  new  systems.  Implementing  IT  is  an  organizational  change  problem,  and 
can  be  successful  only  when  senior  executives  are  willing  to  pay  the  price  that  complex 
cultural  change  entails.  [Ref.  35:  pp.  36-38] 

Secretary  of  Defense  Taft  envisioned  the  bold  nature  of  CALS  as  a  25-year 
infrastructure  modernization  and  process  improvement  effort  —  changing  the  way  we  do 
acquisition  and  logistics.  The  enabler  of  that  change  is  the  infusion  of  information 
technology  and  the  business  process  re-engineering  concepts  driving  today’s  changes  in 
information  management.  Whether  one  views  these  changes  as  evolutionary  or 
revolutionary  is  a  matter  of  perspective.  Regardless  of  perspective,  CALS  involves 
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change!  This  change  has  caused  the  creation  of  a  culture  shock  within  the  acquisition  and 
logistic  communities  of  both  government  and  industry.  Certain  skills  will  become  obsolete 
and  new  skills  will  be  developed.  These  changes  trigger  both  fear  and  excitement  in 
people,  depending  upon  their  individual  assessments  of  how  they  fit  in  the  future.  [Ref 
31] 

In  their  article,  in  1993,  Davidovich  and  Heisterberg  said  CALS  culture  shock  is 
the  result  of  three  discontinuities  of  understanding  between  those  who  see  the  impact  of 
CALS  upon  government  and  industry  and  those  who  see  CALS  as  a  just  another  fad  or 
don't  even  know  what  the  CALS  acronym  means.  They  added  three  reasons  of 
discontinuity;  1)  people  using  the  "CALS  Military  Standards"  for  an  explanation  of  CALS 
while  others  use  the  various  CALS  policy  statements;  2)  resistance  by  other  IT  projects 
from  being  absorbed  into  the  CALS  effort;  and  3)  CALS  advocates  who  have  created  an 
ever  increasing  and  complex  CALS  lexicon. 

Even  one  of  the  most  advanced  countries,  the  United  States,  has  experienced  the 
cultural  shock  from  this  change  which  they  prepared  and  faced;  Korea,  a  developing 
country,  could  also  expect  these  cultural  shocks. 

To  reduce  CALS  culture  shock,  they  suggest  types  of  actions  that  are  grouped 
into  three  themes:  education,  management,  and  funding. 

Education  weakens  culture  shock  by  establishing  a  common  understanding  of 
CALS.  Group  consensus  is  a  visible  indication  that  culture  shock  is  being  reduced  -- 
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focusing  the  group  to  communicate  and  exchange  their  problems  and  solutions  on 
information  technology  and  process  improvement  matters. 

Management  has  many  paths  to  attack  culture  shock  -  establishing  a  testbed  for 
evaluating,  demonstrating  and  rapidly  prototyping  CALS/CITIS  applications.  CITIS 
offers  managers  an  excellent  and  practical  environment  to  deal  with  and  overcome  CALS 
culture  shock. 

Funding  is  the  ammunition  that  quells  culture  shock  -  advocating  funding  with  a 
focus  on  a  business  case,  starting  a  CITIS  business  case  to  develop  the  needed  supporting 
data,  and  establishing  a  relationship  with  DoD  laboratories  dealing  with  information 
technology.  [Ref.  31] 

B.  STATUS  QUO  OF  KOREAN  CALS 

Now,  the  interest  in  CALS  is  increasing  in  Korea,  i.  e.,  several  newspapers 
introduced  CALS,  its  benefits,  successful  examples  in  other  countries  and  the  urgency  of 
the  implementation  in  Korea.  But  this  interest  on  the  industry  side  is  greater  than  on  the 
government  side. 

Now,  in  Korea,  the  CALS  Committee  of  the  EDI  Office  of  the  Computer  and 
Communication  Promotion  Association  of  Korea  (CCPAK)  plays  the  leading  role  for 
CALS  activities  on  the  industrial  side.  Most  of  the  large  industrial  conglomerates 
(Samsung,  Hyundai,  DeaWoo,  Lucky-Goldstar,  Oracle  System  Korea,  and  etc.)  has 
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started  studies  focusing  on  CALS.  CCPAK  has  held  "CALS  Korea  :  the  International 
Conference  &  Exhibition"  in  1994  and  1995. 

On  the  government  side,  the  Ministry  of  Information  &  Communication  (MIC)  and 
the  Ministry  of  Trade,  Industry  &  Energy  (MTIE)  have  established  long  term  plans  for 
CALS.  In  February  1995,  MIC  announced  that  it  will  spend  100  Millions  Won  (US  $ 
125,000)  to  establish  the  master  plan  for  CALS  that  set  out  the  Korean  CALS  vision  and 
provide  direction  for  a  systematic  push  in  this  year. 

MIC  will  use  this  master  plan  as  a  basic  guide  line  for  the  national  CALS 
implementation  and  the  plan  to  connect  with  the  Industry  Information  Network  project. 
They  will  also  use  it  to  create  development  plans  to  fit  the  character  of  the  each  industry. 

MIC  plan  to  establish  the  "CALS  Korea  Co-operation  Committee  (CKCC, 
proposed)"  from  the  CALS  Committee  of  CCPAK  with  related  institutes  and  associations, 
CKCC  will  analyze  CALS  related  businesses,  urge  co-operation  between  associations  and 
companies,  and  take  a  role  for  consulting  and  assisting  international  projects.  [Ref.  36] 

Also  MND  is  studying  the  issue  to  develop  a  basic  plan  for  Korean  CALS  setup. 
More  detailed  plan  will  be  developed  by  the  Korea  Institute  for  Defense  Information 
System  (IDIS).  Additionally,  the  Agency  for  Defense  Development  (ADD)  will  develop 
an  Integrated  Weapon  Systems  Data  Base  (IWSDB)  as  a  model  for  the  services. 
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C.  RECOMMENDATIONS 


This  section  presents  some  recommendations  for  a  Korean  CALS  Implementation 

plan. 

1.  Use  The  Prototype  Implementation  Strategy 

A  prototype  strategy  will  avoid  the  large  sunk  investment  in  rapidly  changing 
technologies.  Prototypes  will  train  people  and  help  overcome  resistance  and  culture  shock. 
This  process  can  itself  take  years,  so  we  need  to  start  these  processes  early  in  our  effort. 

The  Korean  Armed  Forces  (KAF)  has  a  relatively  small  size  compared  to  the 
United  States'.  Instead  of  one  or  two  prototyping  sites  in  each  service,  a  joint  prototyping 
site  which  has  departments  of  each  service  could  be  tested  and  demonstrate  several  CALS 
projects  on  the  same  equipment.  It  could  help  avoid  potential  conflicts  from  use  of 
different  standards  in  each  service  from  the  beginning  of  the  implementation. 

2.  Exchange  Personnel  to  Effect  Technology  Transfer 

Professor  Thomas  J.  Allen  from  the  Sloan  School  of  Management  at  MIT  did 
extensive  research  into  the  process  of  technology  transfer  under  the  sponsorship  of  the 
U.S.  National  Science  Foundation.  The  main  finding  of  his  analysis,  now  widely  accepted, 
is  that  the  most  effective  way  of  transferring  technology  is  through  the  relatively  long  term 
exchange  of  personnel.  Personnel  assigned  to  an  outside  organization  establish  a  network 
of  informal  contacts  outside  of  their  native  organizations  and  then  tend  to  serve  as 
"gatekeepers"  who  continue  to  bring  fresh  ideas  into  their  organizations  long  after  their 
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return.  Personnel  from  outside  the  organization  who  come  to  work  inside  on  a  day  to  day 
basis,  tend  to  stimulate  a  higher  level  of  activity  and  exchange  of  ideas.  [Ref.  37] 

Based  on  Allen's  research,  it  would  be  available  to  exchange  personnel  between  the 
U.S.  and  Korean  CALS  efforts,  for  example:  1)  send  liaison  personnel  from  Korean  CALS 
project  Office  to  JCALS  or  DISA  for  long  term  assignment  (1  to  3  years);  2)  try  to  get 
some  manpower  from  the  U.S.  ISG  or  a  consulting  contractor  from  the  U.S.  to  work  in 
Korea  to  establish  a  Korean  ISG  through  CALS  International. 

3.  Establish  Standards 

We  found  sufficient  reasons  why  we  should  introduce  CALS  as  soon  as  possible. 
Nowadays  the  Korean  domestic  defense  industry  already  has  some  degree  of  capability  to 
develop  new  weapon  systems  (e.g.,  K1  tank  in  Army,  FFK,  destroyer  level  of  ship  in 
Navy).  Unfortunately,  those  developments  were  done  without  a  frill  architecture  of  the 
CALS  consideration.  Maybe  some  of  the  industrial  CALS-compatible  applications  (e.g., 
EDI,  SGML)  are  partially  used  by  big  businesses  (not  in  the  military  project  but  in  the 
business  trade  or  other  purpose)  but  not  integrated  together.  The  most  problematic  issue  is 
that  there  are  no  documented  standards  for  the  CALS  environment  of  Korea.  Therefore 
the  most  urgent  phase  of  the  CALS  implementation  should  be  the  establishment  of 
standards.  As  the  U.S.  CALS  standards  set  their  direction  for  the  international  integration 
of  CALS,  it  will  be  preferable  for  MND  to  follow  the  format  of  the  U.S.  standards.  For 
KFP,  at  least  five  classes  of  standards  are  needed.  Those  are  1)  SGML  for  the  text 
standard,  2)  IGES  for  the  vector  graphics,  3)  CCITT  Gr.  4  for  raster  graphics,  4) 
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M1L-STD-1388-2D  for  the  logistics  data,  and  5)  MIL-HDBK-59B  for  overall  instruction 
about  data  acquisition  and  usage. 

4.  Build  Defense  Information  Infrastructure 

After  the  standards  have  been  established,  the  real  architecture  design  for  CALS 
will  be  possible  as  the  next  phase  of  CALS  implementation.  For  example,  the  three  big 
contractors  for  the  Korean  Fighter  Plane  (KFP)  could  have  the  engineering  data 
depository  and  other  100  subcontractors  might  have  CALS  network  capability.  For  CALS 
data  transmission,  a  100  Mbps  network  capability  is  required.  To  acquire  this  transmission 
capability,  the  MND  project  launched  recently  might  be  done  with  optical  fiber.  When  we 
consider  the  huge  amount  of  the  KFP  investment,  the  cost  of  building  the  network  is  quite 
modest.  Therefore,  a  good  chance  exists  to  obtain  funding  for  infrastructure  construction. 
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VL  CONCLUSION 


The  goal  of  CALS  is  to  move  from  the  traditional,  paper-based  organization  to  an 
integrated  digital  information-oriented  enterprise.  However,  achieving  this  transition  will 
require  new  management  approaches  and  the  cooperative  involvement  of  the  participating 
enterprise  in  solving  current  and  future  problems,  such  as  organizational  and  cultural 
issues,  legal  and  security  issues,  technology  selection,  and  the  integration  of  legacy  data. 
[Ref.  2,  p  58] 

The  Government  and  the  Military  of  the  Republic  of  Korea,  having  recognized  the 
potential  benefits  of  CALS,  is  now  in  the  process  of  defining  its  implementation  strategy 
and  plans.  Additionally,  MND  is  actively  exploring  CALS  for  the  benefits  described 
above,  and  to  improve  interoperability  with  Korea's  military  allies. 

The  conclusion  reached  by  this  thesis  research  is  that  it  will  be  a  matter  of  how, 
rather  than  if,  the  Korean  MND  will  incorporate  CALS  into  its  operations  and 
infrastructure.  The  scope  of  CALS  has  grown  to  the  point  that  it  now  represents  the  bulk 
of  the  information  technology  revolution  as  it  impacts  on  the  materiel  support  of  a  modem 
military. 

Learning  from  the  U.S.  experience,  we  see  that  the  challenges  of  CALS  spring 
from  both  the  technology  involved  and  its  pervasive  organizational  impact. 
Organizationally,  it  is  important  to  involve  all  stakeholders  in  the  process  to  address  their 
concerns  and  achieve  "buy  in."  To  maintain  discipline  in  the  process  a  single  arbiter  must 
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be  in  charge  and  an  explicit  plan  is  required  to  coordinate  the  many  diverse  efforts.  The 
impact  of  changing  procedures  and  culture  must  he  anticipated  and  addressed. 

The  technological  challenges  of  CALS  descend  from  the  rapid  rate  of  change  of 
the  technology,  and  the  difficulty  of  establishing  standards.  The  long  lead  time  required 
for  infrastructure  installation  requires  an  early  effort  to  build,  but  for  other  components  of 
the  system  (e.g.,  processors,  storage,  display,  and  software)  the  use  of  prototype  and  a 
phased,  modular  procurement  approach  will  allow  a  more  cost  effective  way  to  benefit 
from  incremental  technological  development. 

The  definition  of  international  standards  is  currently  underway  by  the  CALS  ISG. 
It  is  concluded  that  it  would  be  to  the  benefit  of  Korea  to  participate  in  this  process  by 
exchanging  personnel.  This  would  ensure  that  Korean  requirements  are  included,  such  as 
Korean  letter  standards,  and  that  Korea  remains  on  the  leading  edge  of  technological 
development  and  military  prowess. 
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APPENDIX:  ACRONYM 


ADD 

Agency  for  Defense  Development 

ADM 

Association  for  Information  and  Image  Management 

AIS 

Automated  Information  Systems 

ANSI 

American  National  Standard  Institute 

AP 

Acquisition  Plan 

AP 

Application  Protocol 

ARM 

Application  Reference  Model 

ARPANET 

Advanced  Research  Project  Agency  computer  NETwork 

Ascn 

American  Standard  Code  for  Information  Interchange 

ASME 

American  Society  of  Mechanical  Engineers 

BBS 

electronic  bulletin  boards 

CAC 

Contractor's  Approach  to  CALS 

CAD 

computer-aided  design 

CALS 

Continuous  Acquisition  and  Life-cycle  Support 
or  Computer-aided  Acquisition  and  Logistics  Support 

CALS  ISG 

CALS  Industrial  Steering  Group 

CBC 

ConstructionBattalion  Center 

CCPAK 

Computer  and  Communication  Promotion  Association  of  Korea 

CCITT 

Consultative  Committee  for  International  Telegraph  and  Telephone 

CDRL 

Contract  Data  Requirements  Lists 

CD-ROM 

Compact  Disk  Read  Only  Memory 

CE 

Concurrent  Engineering 

CGM 

Computer  Graphics  Metafile 

CIM 

Corporate  Information  management 

CITIS 

Contractor  Integrated  Technical  Information  Services 

CKCC 

CALS  Korea  Co-operation  Committee 

COTS 

commercial-off-the-  shelf 

DDN 

Defense  Data  Network 

DFARS 

Defense  Federal  Acquisition  Supplement 

DB 

defense  integrated  infostructure 

DISA 

Defense  Information  Systems  Agency 

DISN 

Defense  Information  Systems  Network 

DLA 

Defense  Logistics  Agency 

DoN 

Department  of  Navy 

DoD 

Department  of  Defense 

DPS 

Defense  Printing  Service 

DSREDS 

Digital  Storage  and  Retrieval  Engineering  Data  System 

DTD 

Document  Type  Definition 

EAC 

Electrical  Applications  Committee 
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EC 

Electronic  Commerce 

ECAT 

Electronic  Commerce  Acquisition  Team 

ECARDS 

Engineering  Computer  Aided  Retrieval  and  Distribution  System 

EDCARS 

Engineering  Data  Computer-Assisted  Retrieval  System 

EDI 

Electronic  Data  Interchange 

EDIF 

Electronic  Design  Interchange  Format 

EFT 

electronic  funds  transfer 

El 

Enterprise  Integration 

EMD 

Engineering  and  Manufacturing  Development 

FIPS 

Federal  Information  Processing  Standard 

FOSI 

Formatting  Output  Specification  Instance 

FDDI 

Fiber-Optic  Distributed  Data  Interface 

FRC 

Final  Reproducible  Copies 

FTAM 

File  Transfer  and  Access  Management 

GAO 

Government  Accounting  Office 

GCO 

Government  Concept  of  Operations 

GD 

General  Dynamics 

GDMS 

Global  Data  Management  System 

GD/DDB 

Global  Dictionary/Directory  Data  Base 

GFI 

Government  Furnished  Information 

GO  SIP 

Government  Open  Systems  Interconnection  Profile 

HST 

Hubble  Space  Telescope 

HTTP 

HyperText  Transfer  Protocol 

HUI 

human-user  interface 

IGES 

Initial  Graphics  Exchange  Specification 

IAW 

in  accordance  with 

1DIS 

Korea  Institute  for  Defense  Information  System 

IETM 

Interactive  Electronic  TMs 

ILS 

Integrated  Logistics  Support 

IMS 

information  management  system 

IPC 

Interconnecting  and  Packaging  Electronic  Circuits 

IPO 

IGES/PDES  Organization 

ISO 

International  Organization  for  Standardization 

IT 

Information  Technologies 

IWSDB 

Integrated  Weapon  Systems  Data  Base 

JCALS 

Joint  Computer-aided  Acquisition  and  Logistics  Support 

JEDMICS 

Joint  Engineering  Data  Management  and  Information  Control 
System 

KAF 

Korean  Armed  Forces 

KIDIS 

Korea  Institute  for  Defense  Information  System 

KFP 

Korean  Fighter  Program 

LCC 

Life  Cycle  Cost 

LEM 

Logistic  Element  Manger 
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LEP 

Layered  Electrical  Products 

LRU 

Line  Replaceable  Units 

LSA 

Logistic  Support  Analysis 

LSAR 

Logistic  Support  Analysis  Record 

MIC 

Ministry  of  Information  &  Communication  of  Korea 

MND 

Ministry  of  National  Defense  of  Korea 

MTIE 

Ministry  of  Trade,  Industry  &  Energy 

MLS 

multi-level  secure 

Nil 

national  information  infrastructure 

NIST 

National  Institute  of  Standards  and  Technology 

ODA 

Open  Document  Architecture 

OS 

Output  Specification 

O&S 

Operation  and  Support 

OSI 

Open  Systems  Interconnection 

PC 

Personal  Computer 

PDL 

Page  Description  Language 

P&D 

Production  and  Deployment 

PHD/NSWC 

Port  Hueneme  Division,  Naval  Surface  Warfare  Center 

PMC 

President's  Management  Council 

PM  JCALS 

Program  Manager  JCALS 

RJP 

Request  For  Proposal  RFP 

RIG 

Regional  Interest  Groups 

RISC 

Reduced  Instruction  Set  Computing 

ROK 

Republic  of  Korea 

SGML 

Standard  Generalized  Markup  Language 

SOSC 

System  operational  Support  Center 

SOW 

Statement  of  Work 

TACOM 

Tank  Automation  Command 

TCP/IP 

Transmission  Control  Protocol/Intemet  Protocol 

TDCC 

Transportation  Data  Coordinating  Committee 

TOP 

Technical  Data  Package 

TMCR 

TM  Contract  Requirements 

TMIS 

Technical  Management  Information  System 

TMs/TOs 

Technical  Manuals  or  Technical  Orders 

TRM 

Technical  Reference  Model 

USFK 

United  States  Forces  in  Korea 

UN/EDIFACT 

United  Nations/Electronic  Data  Interchnage  For  Administration, 
Commerce,  and  Transport 

VAN 

Value-Added  Communication  Network 

VHDL 

Very  Hardware  Description  Language 

VHSIC 

Very  High  Speed  Integrated  Circuit 

VT 

Virtual  Terminal 

WORM 

Write  Once  Read  Many-times 
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WRA 

wss 

WWW 


Weapon  Replaceable  Assemblies 
Workstation  Server 
World  Wide  Web 
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